1.关于碎片问题：
CMS采用Mark-Sweep算法进行垃圾会后，不会对堆空间进行整理和压缩，每次回收后不可避免会有一些碎片产生。
-XX:+UseCMSCompactAtFullCollection default true 对老年代进行压缩，可能影响性能，但是可以消除碎片。
-XX:CMSFullGCsBeforeCompaction=n CMS进行n次full gc后进行一次压缩。如果n=0,每次full gc后都会进行碎片压缩。
-XX:+UseCMSCompactAtFullCollection default true 对老年代进行压缩，可能影响性能，但是可以消除碎片。
-XX:CMSFullGCsBeforeCompaction=n CMS进行n次full gc后进行一次压缩。如果n=0,每次full gc后都会进行碎片压缩。
2.关于CPU问题
CMS需要CPU有更多的“核”，在CMS活动的时候，也会占用较多的“核”。
–XX:+CMSIncrementalMode default false 并发收集递增进行，周期性把cpu资源让给正在运行的应用。
–XX:+CMSIncrementalPacing default false 根据应用程序的行为自动调整每次执行的垃圾回收任务的数量
–XX:ParallelGCThreads=n (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8) 并发垃圾回收线程数
-XX:CMSIncrementalDutyCycleMin=n default 0 每次增量回收垃圾的占总垃圾回收任务的最小比例
-XX:CMSIncrementalDutyCycle=n default 10 每次增量回收垃圾的占总垃圾回收任务的比例
–XX:+CMSIncrementalMode default false 并发收集递增进行，周期性把cpu资源让给正在运行的应用。
–XX:+CMSIncrementalPacing default false 根据应用程序的行为自动调整每次执行的垃圾回收任务的数量
–XX:ParallelGCThreads=n (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8) 并发垃圾回收线程数
-XX:CMSIncrementalDutyCycleMin=n default 0 每次增量回收垃圾的占总垃圾回收任务的最小比例
-XX:CMSIncrementalDutyCycle=n default 10 每次增量回收垃圾的占总垃圾回收任务的比例
3.关于空间问题
CMS需要更多的内存，一方面是碎片问题，另一方面是对老年代回收不是在老年代满的时候，而是当老年代内存达到一定比例。-XX:CMSIntiatingOccupancyFractio=n 当老年代内存使用达到n%,开始会后 jdk5 默认是68% jdk6默认92%CMSInitiatingOccupancyFraction = (100 - MinHeapFreeRatio) + (CMSTriggerRatio * MinHeapFreeRatio / 100)
几条经验：
1. java -server
2. 设置Xms=Xmx=3/4物理内存
3. 如果是CPU密集型服务器，使用–XX:+UseParallelOldGC, 否则–XX:+UseConcMarkSweepGC
4. 新生代,Parallel/ParallelOld可设大于Xmx1/4，CMS可设小，小于Xmx1/4
5. 优化程序，特别是每个用户的session中的集合类等。我们的一个模块中session中曾经为每个用户使用了一个ConcurrentHashMap, 里面通常只有几条记录，后来改成数组之后，每台机大概节约了1~2G内存。
3067
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
