错误使用线程池导致OOM javajvm内存

现象描述在线上运行了几个月的服务突然爆出OOM，重启之后隔几天又再次爆出OOM。就把内存从512M加大到了2G，风平浪静一周后再次爆出OOM，这就只能是代码问题了！！！
排查过程由于线上没有jvm dump文件，就只能人肉排查代码了。
嫌疑一：全量查询 select * from table 这种SQL，当数据量够大的是否就会导致OOM。
但是这个项目中没有这样的查询，只能继续排查。
嫌疑二：错误操作集合出于业务目的，在筛选时需要把专用的和公用的handler都放入备选集合，于是就出现了下列错误代码。

public class Manager{private List commonHandlers = new ArrayList<>(); private Map handlers = new Hashmap<>(); public List dispatch(Condition condition) { List alternativeHandlers = handlers.get(condition.getType()); alternativeHandlers.addAll(CommonHandlers); // 公用的处理器也需要加入备选// 其他筛选操作 handlers = alternativeHandlers.stream() .filter(.......) .....return handlers; } }

每一次调用dispatch方法都会修改handlers中的List导致数据越来越多，因为数据量较小在短期内先爆出了业务逻辑BUG，同时这类BUG理论上也会导致OOM。但是排查发现这个项目中没有这样的操作，只能继续排查。
嫌疑三：线程池 Java8 HotSpot JVM 的GC是通过可达性分析来判定垃圾的，而这个可达性的出发点就是 GC Root 有 Stack Local、Class、JNI Local、JNI Global、Live Thread，其中前2个已经被前2步排除了嫌疑，而本项目又不涉及到JNI相关操作，那么就剩下Live Thread一种可能了。
【错误使用线程池导致OOM】根据前2步可知，线程所引用的对象都没有OOM的可能，那么就只可能是线程本身一直在增加，最终导致OOM。按照这个思路发现了下面的嫌疑代码

public class Handler{private ThreadPoolExecutor executor = new ThreadPoolExecutor(.....); public void handle(Object arg) { executor.submit(()->{ // 实际处理的业务逻辑 ......... }); }}

这个代码的问题在于，Handler本身会被Manager定时刷新，每次刷新时会构建一个新的Handler并将旧的丢弃。但是旧的Handler中线程池并没有被关闭，线程池中的线程也就会一直存活，随着时间的增加，废弃的线程越来越多最终导致了OOM。
锁定罪犯: 需要更新的对象所引用的线程池，在对象创建新实例时，旧实例的线程池没有被关闭，而是被直接抛弃了。
解决方案: 丢弃旧的Handler之前手动shutdown()
关联问题？单例对象引用的线程池或者线程，主线程退出时没有关闭为什么没有造成OOM？
一个Java Application独占一个JVM进程，退出主线程时会退出进程，进程中的所有线程也将退出。退出了也就释放了内存了当然也不会有内存问题了。
没有shutdown的线程会怎样？
会继续运行，直到被shutdown，或者直到进程退出时子线程才会退出