JAXBContext.newInstance 为何会引发内存泄漏？

你的常规理解其实没错——正常情况下方法内的局部对象在执行完毕后确实会成为GC的回收目标，但JAXBContext的特殊实现逻辑打破了这个常规，我来给你拆解几个核心原因：

• 静态缓存的持久化持有
  JAXB的默认实现（比如Oracle/Sun的RI）内部维护了一个静态缓存，当你调用JAXBContext.newInstance()时，创建好的JAXBContext实例会被缓存起来（以绑定的类集合、上下文配置为key）。这个缓存是全局静态的，只要JVM进程不终止，就不会主动清理。也就是说，你以为的“局部对象”其实被静态引用牢牢攥住了，根本没机会被GC。如果你的应用频繁创建不同配置的JAXBContext（比如每次绑定不同的临时类），缓存会持续膨胀，最终导致内存泄漏。

• 类加载器的意外引用
  JAXBContext初始化时会持有当前线程的上下文类加载器引用。如果你的应用是Web应用或者有热部署需求，当你卸载一个模块时，这个模块的类加载器本应该被GC回收，但如果JAXBContext的缓存还拿着它的引用，整个类加载器下的所有类、对象都会被牵连，无法被回收——这是Java内存泄漏里非常典型的“类加载器泄漏”场景。

• ThreadLocal的残留引用
  部分JAXB实现会在初始化过程中用ThreadLocal存储临时的元数据或上下文状态，但有些场景下这些ThreadLocal的引用没有被正确清理。如果你的应用使用了线程池（线程长期存活），ThreadLocal里的对象会一直被线程实例持有，哪怕JAXBContext的局部代码已经执行完毕，这些关联的元数据、类引用也无法被GC回收。

• 元数据的持久化存储
  JAXBContext在创建时会解析绑定类的所有元数据（比如@XmlRootElement注解、XML结构映射信息），这些元数据会被存在JAXBContext实例内部。一旦JAXBContext被静态缓存持有，这些元数据也会跟着“永生”——如果你的应用动态生成了很多临时JAXB类，每次创建JAXBContext都会绑定这些类，缓存里的实例会一直攥着这些类的引用，导致类无法被卸载，进而占用大量内存。

简单来说，问题的核心就是：你以为的“局部对象”JAXBContext，其实被静态缓存、类加载器、线程池等长期存活的对象间接持有了，根本没机会被GC回收，这才导致了内存泄漏。

内容的提问来源于stack exchange，提问作者pjj