一、使用 MemoryAnalyzer软件打开hprof文件
很大有30G，win内存24GB，不用担心可以打开，ma软件能够生成索引文件，逐块分析内存，如下图。
大约需要4小时。
overview中开不到具体信息。
二、使用Leak Suspects功能继续分析
竟然是classloader和jarfile
9,907,656,360 (46.19%) /1024/1024/1024=9.2GB。
hive和hadoop的jar包加在一起好像都没有这么大。
点开jarfile看看，没有具体内容信息。
三、使用Top Components分析
具体看看：
同一jar为什么会在内存中，经过查询资料后发现，hive每个任务的jar是相互隔离的。就是使用的不同classloader，加载所有的jar包。即使同一个class被不同的classloader加载，jvm也不认为是同一个类。这样就能避免不同用户UDF函数中定义同名类的冲突了。
下图中的展开后都是这个jar auth-adapter-1.0.0.jar，同一个jar被加载到内存很多次。
怎么会有这个多jar文件呢，肯定有问题。1400万个jar被加载。
随意找个jarfile看看他的GC root在哪里，导致其无法被GC回收。
是个线程，就是自己写的hive插件的线程池启动的线程。排查自己代码吧。
找到自己的线程池。
参考文章：
线程池与垃圾回收(GC)
JAVA 多线程并发编程 - 避坑指南
Memory Analyzer内存泄漏OOM基础概念
自己定义的线程池，其中NamedThreadFactory没有自定义classloader，其默认使用父线程的classloader，随类启动，没有定义shutdown，本来以为hive只有一个classloader，分析后发现在hiveserver2端，每个任务都有一个classloader。任务虽然结束了，但是线程池的线程没有被关闭。导致其持有的父线程的classloader，仍然被链接，无法被GC回收。
val pool: ExecutorService = new ThreadPoolExecutor(1, // 核心线程数2, // 最大线程数20, // 非核心线程的空闲超时时间（秒）TimeUnit.SECONDS, // 时间单位new ArrayBlockingQueue(2), // 工作队列new NamedThreadFactory(prefix, true), // 自定义线程工厂new ThreadPoolExecutor.DiscardPolicy() // 拒绝策略)
同理jarfile是因classloader加载的，classloader内存占用也是相同的原因。
因此，hive的每个任务执行结束后都应该调用 pool.shutdown()。
