一次GC问题定位
同事有段代码执行时间过长,需要进行优化,
Hashmultimap<Int,Bean> map = ...; for (400w*96) { // 计算过程 Bean = doCompute(); // 缓存计算结果 map.put(int,Bean); }
刚开始以为是计算过程doCompute效率低造成的,所以想各种方法优化计算,提前计算、多线程、。。。。等等等等,最终如下
// 多线程计算 .... // 计算结果放入队列 ConcurrentLinkedQueue queue = ...; queue.offer(doCompute()); ..... // 队列数据放入缓存 Hashmultimap<Int,Bean> map = ...; map.put(int,queue.poll());
但还是不行,跑跑就cpu 100%,找不到什么原因,直到快下班时突然想到是不是内存引起的,然后放到服务器上一执行,-Xms20G -Xmx20G,没有任何问题。
分析了下,找到了原因(纯分析,下周打印下jvm日志验证下):
对于Hashmultimap和ConcurrentLinkedQueue来说,因为是循环单个放入缓存,所以jvm是逐渐到达最大堆栈的,而一旦jvm发现内存不够用,就启动GC过程,但GC结束发现还是不够用(因为没有实例需要回收)就又启动GC,。。。,循环往复,业务代码不能跑,CPU全被GC占满,而且也不抛内存溢出的异常。
问题定位过程曲折:先入为主容易钻死胡同、好为人师的人真nm多、要相信jvm的计算生产水平。。。。
另外,记录下一些可能用到的知识:
JVM初始分配的内存默认是物理内存的1/64,默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制,-XX:MinHeapFreeRatio=40.
JVM最大分配的内存默认是物理内存的1/4,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制,-XX:MaxHeapFreeRatio=70.
通过free查看到的空闲内存不能完全分配到jvm,能分配的比例应该和jvm厂商、os有关。