Tomcat GC Log，怎么看GC有没有问题，每个参数都是什么意思。服务器突然挂了，log没有里任何异常信息！

98277.469: [GC 98277.469: [ParNew: 724452K->49066K(853376K), 0.0701960 secs] 841423K->166244K(1877376K), 0.0707240 secs] [Times: user=0.54 sys=0.00, real=0.07 secs]

ParNew垃圾回收器的类型，这个是处理新生代的，724452K->49066K清理前后的大小。(853376K)总大小，0.0701960 secs 消耗时间

841423K->166244K(1877376K), 0.0707240 secs zhege 可能就是老年代的回收了。也是大小，时间。

[Times: user=0.59 sys=0.00, real=0.08 secs] 这个就不清楚了。第一个猜测可能是服务暂停响应时间吧。

从给出的日志好像看不出问题啊。

System.gc()是“呼叫”垃圾回收器回收垃圾的，这么说不太严谨，其实但是只是“通知”而已，具体回收不回收由垃圾收集器的算法决定，你完全可以开发一个什么也不干的垃圾收集器，或者等内存被占用超过一定比例再回收的垃圾收集器。

finalize()方法是一个类对象在销毁时会被调用的方法，垃圾收集器在发现这个类对象不会再被使用时就会回收内存，也就是销毁该对象，从而finalize()被调用了。你这个程序System.gc()是最后一句，显然前一句创建的Book对象后面不会被使用了，所以JDK带的垃圾回收算法就会调用该对象的销毁方法来回收了。

会。由于我们这里用的是阿里云容器，所以很多命令没有权限，不过好在有一些可视化的界面，一样可以判断问题，首先看一下JVM和cpu使用率吧，

不断重启的podJVM分布.png

看这个内存占用示意图，明显是有什么大对象占用了太多的堆空间，然后一直gc不掉，反复GC,自然CPU也跟着上去了，然后触发自动重启机制，反复如此，接下来找tail一下gc日志，果然各种报各种Full GC (Allocation Failure，top一下cpu占用也飙升上去了，得了，搞一下崩溃时候的dump日志看一下吧，看看到底是哪些对象死活gc不掉吧，考虑最近没有上线，而且出现的这么有规律，应该是个定时任务触发的场景，不过这里却卡了壳，没有权限，找运维大佬给搞一下吧，下班了？结果第二天才给我dump日志（这个工作效率，比我还摸鱼），拿出来分析一下，找个mat分析工具，虽然我也看不懂，但是结果度娘，也能找个七七八八

image.png

首先映入眼帘的是这个线程明显有问题，

image.png

image.png

再看看大对象，也是这个线程（97.70%），就你了，点进去看看,

41万个从库里查出来的映射对象，应该就是他了

跟着调用链，一层层往下找，果然是个定时任务入口，不管了，先给他暂停了，（开着也卡在某个地方执行不过，不过先暂停观察一下），停掉之后果然pod不再重启。

---