如何使用JProfiler定位Java内存泄漏的根源？

• 深入追踪线程引用链
  在Heap Walker中选中未被回收的目标字符串对象，切换到「References」标签页，逐层展开线程对象的引用树。线程对象的引用通常关联到线程上下文（如ThreadLocal、任务队列、未结束的调用栈），顺着层级往下找，就能看到是线程的哪个具体属性（比如静态集合、ThreadLocal变量、未完成的任务实例）持有了字符串的强引用。

• 使用「Path to GC Root」功能
  选中目标字符串，点击工具栏的「Path to GC Root」，选择「Exclude weak references」（弱引用不会阻止垃圾回收，过滤后剩下的就是导致泄漏的强引用链）。通过这条完整的引用路径，能直接定位到最终持有引用的类或对象——比如可能是HTML解析后字符串被存到了静态List，或是线程池的任务未销毁导致引用残留。

• 对比堆快照锁定新增引用
  在HTML解析前后各生成一次堆快照，用JProfiler的「Compare Snapshots」功能筛选出新增的字符串对象，查看这些对象的引用来源。这种对比能快速缩小范围，找到解析操作后额外持有字符串的对象。

• 重点排查线程相关存储
  既然引用链指向thread object，优先检查以下场景：

  • ThreadLocal变量：解析完成后是否未调用remove()，导致线程复用时一直持有旧字符串引用；
  • 线程池任务：解析任务（Runnable/Callable）是否仍被线程池队列或线程持有，未被正常清理；
  • 静态集合：解析后的字符串是否被存入静态Map/List且未做过期清理；
  • 线程上下文类加载器：是否意外持有包含目标字符串的对象实例。

• 验证泄漏点
  找到可疑的引用持有者后，修改代码（如清理ThreadLocal、移除静态集合元素、确保任务执行后被回收），重新用JProfiler分析，确认目标字符串能否被正常垃圾回收，以此验证泄漏点是否正确。

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