问题描述：
32位Win7系统下 Eclipse打开便闪退，或者稍微维持十几分钟或半小时，还是自动关闭，在虚拟机桌面内同样的配置和设置就没有这个问题，我自己电脑3G内存就会出现这样的闪退或者自动关闭。
我的是maven项目，多个maven子模块同时更新同步svn，也会自动退出，电脑CPU经常100%，物理内存使用达到80%。
问题解决：
网搜解决方法，eclipse打不开闪退解决方式
1、通过在命令行中输入“where java”，找到除jdk目录下的所有java相关程序，直接删掉（一般会在C:\WINDOWS\system32下）
2、内存不足，打开Eclipse目录下的eclipse.ini，把里面的-Xmx512m改成-Xmx256m
3、检查环境变量，path变量中将jdk路径放在最前边（开头的“.;”直接后边）
4、检查环境变量，path变量中将jdk中的jre路径放在最前边（开头的“.;”直接后边）
5、传言中的万能方案（不过估计非万能）：把jdk目录下的jre目录直接复制到eclipse目录下
6、删除文件：[workspace]/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
7、打开Eclipse的Windows->Preferences->Java->Compiler，可以看到Eclipse支持的JDK的版本。这里是1.7，所以，JDK升级到1.8后就会影响这个版本Eclipse的运行了。
8、修改堆内存：
-XX:PermSize=2048m 持久带堆的初始大小
-XX:MaxPermSize=2048M 持久带堆的最大值
我的实验：
提示删/修前备份
1.C:\WINDOWS\system32下没找到java相关程序，也就没删。
2.内存早已改为768m，所以不是这个问题。
3、4.将jdk、jre放在开头的“.;”的后面，仍然不解决问题。
5.根据问题实际情况和3、4做的尝试，肯定不是jdk或jre找不到的问题，我没尝试5。
6.删除文件：[workspace]/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi，然后重新打开Eclipse。
Eclipse和工程都正常了（工程不需要重新导入）。该方案我打开eclipse一分钟就闪退，后来我有恢复删除文件了。
7.我用的是方案7,可以使得运行时间长一些，但还是偶尔会退出。
8. 我的电脑内存是3G,最后我修改了-XX:PermSize=128m -XX:MaxPermSize=256m，最终解决了，再也没有出现闪退或者
自动退出。
---------------------
参数解释及相关优化方案：
Ⅰ、内存代的优化
-Xms 初始总堆内存，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。
非堆内存分配
-Xmx 最大总堆内存，一般设置为物理内存的1/4
-Xmn 年轻带堆内存，sun官方推荐为整个堆的3/8
使用 -Xgcpolicy:gencon 或 -Xgcpolicy:balanced 时，-Xmn 选项相当于设置 -Xmns 和 -Xmnx 选项[IBM]。
使用 -Xgcpolicy:gencon 时，-Xmnx 设置新区域的最大大小。缺省情况下，此选项设置为 -Xmx 选项值的 25%。如果禁用 scavenger，将忽略 -Xmnx 选项[IBM]。
使用 -Xgcpolicy:balanced 时，-Xmnx 设置 Eden 空间的最大大小。缺省情况下，此选项设置为 -Xmx 选项值的 25%[IBM]。
对于 -Xgcpolicy:gencon 和 -Xgcpolicy:balanced 策略，如果您尝试同时使用 -Xmnx 和 -Xmn，那么 JVM 会返回错误[IBM]。
-Xmns 选项根据指定的垃圾回收策略，为新区域或 Eden 空间设置初始大小[IBM]。
-Xmnx 选项根据指定的垃圾回收策略，为新区域或 Eden 空间设置最大大小[IBM]。
-Xscmx 指定缓存的大小；这个参数只应用于 JVM 创建新缓存的情况。如果省略这个选项，那么选择一个与平台相关的默认值（通常是 16MB）。注意，一些操作系统设置可能会限制可分配的共享内存量，例如 Linux 上的 SHMMAX 通常设置为大约 20MB[IBM]。
-XX:PermSize=2048m 持久带堆的初始大小
-XX:MaxPermSize=2048M 持久带堆的最大大小、根据所需设置。如要编译jdk这种、因所编译的类非常多、一定要将该参数设置较大。
例子：
-vmargs：说明后面是VM的参数
-Xms40m：虚拟机占用系统的最小内存
-Xmx256m：虚拟机占用系统的最大内存
-XX:PermSize：最小堆大小。一般报内存不足时,都是说这个太小,
堆空间剩余小于5%就会警告,建议把这个稍微设
大一点,不过要视自己机器内存大小来设置
-XX:MaxPermSize：最大堆大小。这个也适当大些
-Xmx512M的5%为25.6M，理论上要求-Xmx的数值与-XX:MaxPermSize必须大于25.6M
1g内存推荐为：
-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=64M
-XX:MaxPermSize=128M
疑问解答
Q:-Xmn、-XX:NewSize/-XX:MaxNewSize、-XX:NewRatio 3组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么?
A：
高：-XX:NewSize/-XX:MaxNewSize
中：-Xmn
低：-XX:NewRatio
推荐使用-Xmn参数，原因是这个参数简洁，相当于一次设定 NewSize/MaxNewSIze,而且两者相等，适用于生产环境。-Xmn 配合 -Xms/-Xmx,即可将堆内存布局完成。
-Xmn参数是在JDK 1.4 开始支持。
Ⅱ、字节码验证优化
-Xverify:none（关闭Java字节码验证，从而加快了类装入的速度）
Ⅲ、预热方法的缓存
-XX:CompileThreshold=100 方法调用多少次就会被编译成本地机器码
-XX:ParallelGCThreads=4 配置并行收集器的线程数，即：同时有多少个线程一起进行垃圾回收。此值建议配置与CPU数目相等。
Ⅳ、垃圾回收器选择
JVM给出了3种选择：串行收集器、并行收集器、并发收集器。串行收集器只适用于小数据量的情况，所以生产环境的选择主要是并行收集器和并发收集器。
默认情况下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行智能判断。
-XX:+DisableExplicitGC 禁用System.gc()的显示内存回收
-XX:+UseParNewGC 使用并发内存回收(年轻GC)、关注响应时间。注：另一个年轻GC为： -XX:+UseParallelGC 关注吞吐量
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=80
拓展：Java堆内存详解
JVM堆内存分为2块：Heap Space 和 Permanent Space。
Heap 被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。
Permanent 即持久代(Permanent Generation)，主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。但是在JDK8中该区域已经被移除。
新生代 ( Young ) 对象刚创建出来时放在这里、年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个Eden区，2个Survivor区(from 和 to)。
·大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区(两个中的一个)，当一个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当另一个Survivor区也满了的时候，从前一个Survivor区复制过来的并且此时还存活的对象，将可能被复制到年老代。
·2个Survivor区是对称的，没有先后关系，所以同一个Survivor区中可能同时存在从Eden区复制过来对象，和从另一个Survivor区复制过来的对象;而复制到年老区的只有从另一个Survivor区过来的对象。而且，因为需要交换的原因，Survivor区至少有一个是空的。特殊的情况下，根据程序需要，Survivor区是可以配置为多个的(多于2个)，这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。
老年代 ( Old ) 在年轻代中经历了N次(可配置)垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )，即：新生代 ( Young ) = 1/3 的堆空间大小。
老年代 ( Old ) = 2/3 的堆空间大小。其中，新生代 ( Young ) 被细分为 Eden 和 两个 Survivor 区域，这两个 Survivor 区域分别被命名为 from 和 to，以示区分。
默认的，Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 )，即： Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小。
JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。
因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。
持久代( Permanent Generation ) 用于存放静态类型数据，如 Java Class, Method 等。持久代对垃圾回收没有显着影响。但是有些应用可能动态生成或调用一些Class,例如 hibernate CGLib 等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。
总结：当一组对象生成时，内存申请过程：
JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
当Eden区空间足够时，内存申请结束。否则执行下一步。
JVM试图释放在Eden区中所有不活跃的对象( Young GC )。释放后若Eden空间仍然不足以放入新对象，JVM则试图将部分Eden区中活跃对象放入Survivor区。
Survivor区被用来作为Eden区及年老代的中间交换区域。当年老代空间足够时，Survivor区中存活了一定次数的对象会被移到年老代。
当年老代空间不够时，JVM会在年老代进行完全的垃圾回收( Full GC )。
Full GC后，若Survivor区及年老代仍然无法存放从Eden区复制过来的对象，则会导致JVM无法在Eden区为新生成的对象申请内存，即出现"Out of Memory"。
补足：Out of Memory（ OOM ）异常一般主要有如下2种原因：
1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace
这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。
例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。
2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace
通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize 调大(一般256m能满足绝大多数应用程序需求)。将部分Java类放到容器共享区(例如Tomcat share lib)去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。
---------------------