关于OOM（内存溢出）事故的分析与定位（Troubleshooting）

最近公司某个项目出现OOM事故，整理了一下这次解决的思路：

先说java的垃圾回收机制（JAVA GC），Java区别于C++,C++需要开发者自己实现垃圾回收的逻辑，而JAVA开发者则只需要专注于业务开发，因为垃圾回收这件繁琐的事情JVM已经为我们代劳了，从这一点上来说，JAVA还是要做的比较完善一些。

导致OOM（OutOfMemoryError）错误的原因大致有以下几个原因：

(1)、java.lang.OutOfMemoryError: PermGen Space，指的是java永久代（方法区）的空间不足。永久代用于存放类的字节码和常量池，类的字节码被加载后存放在这个区域，这和存放对象实例的堆区是不同的。大多数的JVM实现都不会对永久代进行垃圾回收，因此，只要类加载过多就会出现这个问题。一般的应用程序都不会产生这个错误。但是，对于web服务器会产生大量的JSP，jsp在运行时被动态的编译成Java Servlet类，然后加载到方法区，因此很多jsp的web工程会产生这个异常。

(2)、java.lang.OutOfMemoryError: Java heap space，表示java堆空间不足。当程序申请使用更多的内存时，假使java堆内存已经无法满足应用程序的需要，就会抛出异常【比较常见】。

(3)、java.lang.OutOfMemoryError: GC overhead limit exceeded，是并行或者并发垃圾回收器的GC回收时间过长、超过98%的时间用来做GC并且回收了不到2%的堆内存时抛出的异常，用来提前预警，避免内存过小导致应用不能正常work。

(4)、java.lang.OutOfMemoryError: unable to create new native thread，本质原因是创建了太多的线程，而系统允许创建的线程数是有限的。或者是线程使用的资源（内存）过多，系统已经负载不能提供资源给应用了。

如何计算最大线程数？

最大线程数=（操作系统最大可用内存 - JVM内存 - 操作系统预留内存）/ 线程栈大小

其他可能原因：

(1)、java.lang.StackOverflowError，JVM的线程由于递归或者方法调用层次太多，占满了线程堆栈而导致的，线程堆栈的默认大小为1MB。

(2)、java.net.SocketException: too many open file,[某个应用程序使用的文件数量超过了系统最大打开文件数]。

OOM的分析与定位：

错误：java.lang.OutOfMemoryError: unable to create new native thread

1.计算内存，判断可用资源能创建的最多线程数是否满足应用的需求；free -m

2.线程数对比，

（a）、ulimit -a （可用看到机器允许使用的最大用户进程数为多少）

（b）、jstack $pid(应用的pid)，打印java线程情况。 jstack $pid | grep "Thread " js.log | wc -l 【这边的值和a步骤获得的值对比一下，a>b正常，但不意味着就正常，这边只是看了JVM创建的应用层线程，JVM本身可能会有一些管理线程存在，而且系统内当前用户下可能也有守护线程在运行。用pstack 继续深究。】pstack | awk '{print $3}' | grep appuser | wc -l

观察到问题出现在某个时间节点，且线程堵塞在一个打印日志的语句上<log4j>，该时间节点上没有cronjob，那么系统会不会有I/O密集型的其他任务，比如归档日志、磁盘备份呢？大致判断是日志切割导致I/O增大的，再继续深究一下（结合系统使用的服务框架）。

调整tomcat线程池的最大设置为1600，结合QA压测，重现问题后基本锁定问题。

商讨解决方案：

（1）将全部应用改为直接使用Log4j的日志滚动功能；

（2）调整tomcat的线程池线程数；

（3）升级Log4j日志，使用Logback或者Log4j2。

为了更快速的定位分析问题，可以写一个简易的脚本，去迅速定位问题。（如需脚本，请留言，我补上。）