在流量大致稳定的情况下, JVM 运行一段时间之后, 它的内存使用会趋于稳定, 我们通常认为这个时候做完一次 Full GC 之后的使用内存为稳定使用内存, 一般我们对 JVM 堆(heap) 大小的设置通常对比这个值做参考, 设置年轻代, 老年代的值. 当发生内存泄漏的时候, FuLL GC 之后的内存使用量表现为逐渐增大, 直到内存全部耗尽, 频繁的发生 full GC. 对于内存泄漏的问题, 我们一般捕获 heap dump, 然后分析, 当一个或一类对象实例所直接或间接占用的内存比例非常高的时候, 或者占用巨大的时候, 我们就会怀疑该类或对象. 那么有没有在不做 heap dump 的情况下, 快速定位某个对象是不是发生内存泄漏的方法呢?
对于 JVM GC overhead 的问题, 通常要在 overhead 很高的时候做 heap dump, 这样捕获的 dump 文件才更有意义. 可是在 GC overhead 很高的时候, 它消耗的 CPU 也很高, 通常把机器的 CPU 全占满. 这个时候尝试去使用 jcmd, jmap 去做 heap dump, 很高的概率会得到这个异常:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:213)
at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:140)
at sun.tools.jcmd.JCmd.main(JCmd.java:129)
那么如何解决这个问题呢?
Java 既有早期的 blocking IO (面向流的Input/output stream, 面向字符的 Reader/Writer), 又有之后加入的 NIO/ NIO 2 (Channel & Buffer). 很多应用都是使用的 早期的 blocking 的 IO. 不论是 blocking IO 还是 NIO 都要注意 socket timeout 问题, 如果不设置, 都会引起应用卡在 IO 的问题.
一般看到 java.lang.NoClassDefFoundError 时, 下一步的操作很明确: 去看看这个类为什么不存在? 不在编译路径上? 这个类文件被损坏? 真的缺少这个类? 或者缺少包含这个类的包? 基本按照这个思路都能找到解决方法. 今天遇到这个情况是, 明明这个类完好无损的就在那里, 却始终抛出这个错误.
正常情况下, 这些 countdown() 方法都不会被忘记调用的, 很多情况都是由于考虑不周全, 对于异常的情况处理不正确引起的. 这和各种连接泄漏(数据库连接泄漏, 外部服务连接池) 是一样的问题, 只不过这是对于关键资源的泄漏.