几种OOM异常分析

OOM为out of memory的简称，称之为内存溢出。

程序中常见的打印有如下几类：

一：

如图：

Java应用程序在启动时会指定所需要的内存大小，其主要被分割成两个不同的部分，分别为Head space(堆空间-Xmx指定)和Permegen(永久代-XX:MaxPermSize指定)，

通常来说，造成如上图异常的基本上程序代码问题而造成的内存泄露。这种异常，通过dump+EMA可以轻松定位。（EMA虽功能强大，但对机器性能内存要求极高）

二：

Java.lang.OutOfMemeoryError:GC overhead limit exceeded

如上异常，即程序在垃圾回收上花费了98%的时间，却收集不回2%的空间，通常这样的异常伴随着CPU的冲高。定位方法同上。

三：

Java.lang.OutOfMemoryError: PermGen space（JAVA8引入了Metaspace区域）

永久代内存被耗尽，永久代的作用是存储每个类的信息，如类加载器引用、运行池常量池、字段数据、方法数据、方法代码、方法字节码等。基本可以推断PermGen占用大小取决于被加载的数量以及类的大小。定位方法同上。

还有很多OOM异常，甚至会触发操作系统的OOM killer去杀掉其它进程。

四：

本节主要讨论下面一种OOM，如图

产生这种异常的原因是由于系统在不停地创建大量的线程，且不进行释放。系统的内存是有限的，分配给JAVA应用的程序也是有限的，系统自身能允许创建的最大线程数计算规则：

(MaxProcessMemory-JVMMemory-ReservedOsMemory)/ThreadStackSize

其中

MaxProcessMemory：指的是一个进程的最大内存

JVMMemory ：JVM内存

ReservedOsMemory：保留的操作系统内存

ThreadStackSize：线程栈的大小

从公式中可以得出结论，系统可创建线程数量与分配给JVM内存大小成反比。

在java程序中，创建一个线程，虚拟机会在JVM内存创建一个Thread对象同时创建一个操作系统线程，且系统线程的内存不占用JVMMemory，而占用系统中剩下的内存，即(MaxProcessMemory - JVMMemory - ReservedOsMemory)。

结论很明显：程序创建的线程不可能无限大。

先讨论第一种情况，即经jstack或dump后，线程的数量确在系统要求的阀值内，报上面异常，该如何？

1.参考之前的参数，可以修改两个变量JVMMemory和ThreadStackSize来满足更多线程创建的要求。

-Xss1024k -Xms4096m -Xmx4096m

2.查看是否操作系统限制了可创建线程数量

执行ulimit -u 可以查看当前用户可创建线程量，如果不满足要求，可以通过修改配置文件调整其大小：

相关配置文件在etc/security/limit.d/XX-nproc.conf中

由于上面配置不合理造成而产生异常，个人认为应属小概率事件。

第二种情况，是程序中存在线程泄露，代码本身有问题，在某些场景，条件下存在线程不断创建而不销毁的BUG。

先看一段代码（取自业务真实代码稍加改写）：

package com.zte.sunquan.demo.netty.server;
import com.google.common.collect.Maps;
import java.util.Map;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class MainController {
    private ExecutorService executor = Executors.newSingleThreadExecutor();
    private static Map map = Maps.newConcurrentMap();
    public void submitTask() {
        for (int i = 0; i < 10; i++) {
            executor.submit(new Runnable() {
                @Override
                public void run() {
       System.out.println(Thread.currentThread().getName() + "正处理");
                }
            });
        }
    }
    public static void main(String[] args) throws InterruptedException {
        while (true) {
            MainController ct1 = new MainController();
            map.put("1", ct1);
            ct1.submitTask();
            map.remove("1");
        }
    }
}

如上表的程序就存在线程泄露，开发人员误以为从map中移除，对象就可以释放，最终交由GC回收，但其实在创建的对象中创建的线程池，由于未关闭，执行完任务后，进入waiting状态，是不会释放的，随着程序运行，线程会越积越多，最终导致OOM的异常。

又或者将main函数，改为一个监听入口，在一般甚至短暂的压力测试中，虽然线程较多，但系统仍可以正常进行，误以为系统运行正常，但大业务、多节点、网络震荡、长时间，商用等能够大量触发该监听的场景中，这类问题才以最终kill系统进程暴露出来。

此外，如上表中的代码，线程池创建的进程，采用Executors中DefaultThreadFactory提供的pool-XXX-thread-XXX命名规则，诚然可以通过jstack打印线程调用栈，但如下面的打印：

.....
"pool-2577-thread-1" #8681 prio=5 os_prio=0 tid=0x00007f8ea4de7800 nid=0x6a0b waiting on condition [0x00007f8cae227000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000000057136f4b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-2576-thread-1" #8680 prio=5 os_prio=0 tid=0x00007f8ea4de6000 nid=0x6a0a waiting on condition [0x00007f8cae72c000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000000057136fa20> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
......

完整打印一直是从pool-1-thread-1到pool-5406-thread-1，很明显代码一直在创建线程池，但从打印输出，却无法分析出罪魁祸首是谁？接下来自然，会去系统日志中搜索pool-开头的线程打印，期望能找到线索，遗憾的是，什么信息也没有。此时问题定位，卡壳了。但可以肯定，代码肯定有前面例子中类似的写法。此时，走查代码，不失为一个好办法。

线索就此断掉了。。。。。

但考虑到是使用JDK并发包提供的功能，那在JDK中Executors类中，创建线程时，增加打印，强制将调用栈的信息打印出来，是否可以找到蛛丝马迹？

确定JDK版本--->获取源码---->修改代码--->编译-------->合入rt.jar ------->复现

我们将最终信息输入到了var/log目录下，需要提前将该目录的权限开放chmod 777 -R

输出日志中，对一些连续创建的线程，观察打印信息，幸运女神出现了，OpticalTopologyAdapter，抓到你了。问题解决！

这种问题的出现，归根到底，是没有对线程池进行管理，开发人员对于线程池的滥用，影响了程序稳定性。

修改的源文件如下：

package java.util.concurrent;

import sun.security.util.SecurityConstants;

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.security.AccessControlContext;
import java.security.AccessControlException;
import java.security.AccessController;
import java.security.PrivilegedAction;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
import java.util.Collection;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

public class Executors {

   
    public static ExecutorService newFixedThreadPool(int nThreads) {
        StackTraceElement[] elements = Thread.currentThread().getStackTrace();
        recordThreadStackInfo("SQ:FixThreadPool: " + Thread.currentThread().getName() + nThreads, elements);
        return new ThreadPoolExecutor(nThreads, nThreads,
                0L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue());
    }

   
    public static ExecutorService newWorkStealingPool(int parallelism) {
        return new ForkJoinPool
                (parallelism,
                        ForkJoinPool.defaultForkJoinWorkerThreadFactory,
                        null, true);
    }

   
    public static ExecutorService newWorkStealingPool() {
        return new ForkJoinPool
                (Runtime.getRuntime().availableProcessors(),
                        ForkJoinPool.defaultForkJoinWorkerThreadFactory,
                        null, true);
    }

   
    public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {
        StackTraceElement[] elements = Thread.currentThread().getStackTrace();
        recordThreadStackInfo("SQ2:FixThreadPool: " + Thread.currentThread().getName() + nThreads, elements);
        return new ThreadPoolExecutor(nThreads, nThreads,
                0L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue(),
                threadFactory);
    }

    
    public static ExecutorService newSingleThreadExecutor() {
        StackTraceElement[] elements = Thread.currentThread().getStackTrace();
        recordThreadStackInfo("SQ1:SingleThread: " + Thread.currentThread().getName(), elements);
        return new FinalizableDelegatedExecutorService
                (new ThreadPoolExecutor(1, 1,
                        0L, TimeUnit.MILLISECONDS,
                        new LinkedBlockingQueue()));
    }

    
    public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
        StackTraceElement[] elements = Thread.currentThread().getStackTrace();
        recordThreadStackInfo("SQ2:SingleThread: " + Thread.currentThread().getName(), elements);
        return new FinalizableDelegatedExecutorService
                (new ThreadPoolExecutor(1, 1,
                        0L, TimeUnit.MILLISECONDS,
                        new LinkedBlockingQueue(),
                        threadFactory));
    }

    
    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                60L, TimeUnit.SECONDS,
                new SynchronousQueue());
    }

    
    public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                60L, TimeUnit.SECONDS,
                new SynchronousQueue(),
                threadFactory);
    }

    
    public static ScheduledExecutorService newSingleThreadScheduledExecutor() {
        return new DelegatedScheduledExecutorService
                (new ScheduledThreadPoolExecutor(1));
    }

    
    public static ScheduledExecutorService newSingleThreadScheduledExecutor(ThreadFactory threadFactory) {
        return new DelegatedScheduledExecutorService
                (new ScheduledThreadPoolExecutor(1, threadFactory));
    }

    
    public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
        return new ScheduledThreadPoolExecutor(corePoolSize);
    }

   
    public static ScheduledExecutorService newScheduledThreadPool(
            int corePoolSize, ThreadFactory threadFactory) {
        return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
    }

    
    public static ExecutorService unconfigurableExecutorService(ExecutorService executor) {
        if (executor == null)
            throw new NullPointerException();
        return new DelegatedExecutorService(executor);
    }

    
    public static ScheduledExecutorService unconfigurableScheduledExecutorService(ScheduledExecutorService executor) {
        if (executor == null)
            throw new NullPointerException();
        return new DelegatedScheduledExecutorService(executor);
    }

    
    public static ThreadFactory defaultThreadFactory() {
        return new DefaultThreadFactory();
    }

    
    public static ThreadFactory privilegedThreadFactory() {
        return new PrivilegedThreadFactory();
    }

    
    public static  Callable callable(Runnable task, T result) {
        if (task == null)
            throw new NullPointerException();
        return new RunnableAdapter(task, result);
    }

   
    public static Callable