jvm性能优化建议

一、Gc繁

Eden已用空间（MB）	618.761	每秒执行41.14次GC	1.原本年轻代就是jvm GC频率最高的地方，如果优化，主要是检查代码，是否频繁创建了一些临时对象。 2.启动脚本 -Xms1024M -Xmx1024M  建议设置一样大，可以减少Gc能耗。
Eden回收次数（次）	168
Old Gen已用空间（MB）	140.185	每秒执行2.26次GC
Old Gen回收次数（次）	86
幸存者0区已用空间（MB）	2.484
幸存者1区已用空间（MB）	0
Perm Gen已用空间（MB）	150.069	空闲率85%	3.永久存储区很少执行GC，空闲率较高的话，建议减少设置：-XX:PermSize=200M
说明	伊甸园GC活动频繁，耗费部分系统开销
改进措施	业务繁忙时GC活动的剧增，反映代码中存在频繁创建与回收对象的现象，请开发侧给予关注并修复

 

二、装载过多的类

	内存已载入的类数量	共享类数量
本次巡检加载类总数	30193	0	1.    不同虚拟机类加载方式不同，有些是饿汉式， 只要有其他类引用了它就会加载; 有些是懒加载，即等到类初始化的时候才被加载； 2.    同时还有一种：当有静态初始化需求的时候才被加载。 这样的情况主要检查下代码看是否引用的类是否都是必要的。
上次巡检加载类总数	17705	0
说明	内存类数量增长了71%，系统负荷较高
改进措施

 

三、线程状态(线程等待的原因有很多，可以用jstack pid 查看)

应用全线程状态分布统计
状态类型	各状态分布数
持续运行线程数	14	1.      线程状态为"in Object.wait()" 说明它获得了监视器之后，又调用了 java.lang.Object.wait() 方法。 每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 "Active Thread"，而其它线程都是 "Waiting Thread"，分别在两个队列 "Entry Set"和 "Wait Set"里面等候。在 "Entry Set"中等待的线程状态是 "Waiting for monitor entry"，而在 "Wait Set"中等待的线程状态是 "in Object.wait()"。 当线程获得了 Monitor，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 "Wait Set"队列。 此时线程状态大致为以下几种:     java.lang.Thread.State: TIMED_WAITING (on object monitor)；     java.lang.Thread.State: WAITING (on object monitor)； 一般都是RMI相关线程（RMI RenewClean、 GC Daemon、RMI Reaper），GC线程（Finalizer），引用对象垃圾回收线程（Reference Handler）等系统线程处于这种状态。 2.      线程状态为"waiting for monitor entry" 意味着它 在等待进入一个临界区 ，所以它在"Entry Set"队列中等待。 此时线程状态一般都是 Blocked:     java.lang.Thread.State: BLOCKED (on object monitor) 如果是这种状态:可能是一个全局锁阻塞住了大量线程。 如果短时间内打印的 thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。 3.      线程状态为"waiting on condition" 说明它在等待另一个条件的发生，来把自己唤醒，或者干脆它是调用了 sleep(N)。 此时线程状态大致为以下几种:     java.lang.Thread.State: WAITING (parking):一直等那个条件发生；     java.lang.Thread.State: TIMED_WAITING (parking或sleeping):定时的，那个条件不到来，也将定时唤醒自己。 如果是这种状态:可能是它们又跑去获取第三方资源，尤其是第三方网络资源，迟迟获取不到Response，导致大量线程进入等待状态。 所以如果你发现有大量的线程都处在 Wait on condition，从线程堆栈看，正等待网络读写，这可能是一个网络瓶颈的征兆，因为网络阻塞导致线程无法执行。
持续休眠线程数	12
部分休眠线程数	0
持续等待线程数	245
部分等待线程数	9
分析说明	内存中再次出现大量的pool线程与CmpfScheduler_Worke线程，且均处于等待状态
改进措施	在业务量高峰时期，系统会fork出许多连接池线程与CmpfScheduler_Worke线程，且均不工作。请开发侧关注该现象。

 

———————————————