Linux环境Tomcat8部署的Java Web应用Native内存泄漏排查求助

一、先搞懂 JVM_FindSignal 到底是干啥的 #

这是HotSpot JVM底层的核心函数，主要负责和操作系统的信号机制打交道——简单说就是查找、注册或者映射操作系统级别的信号（比如SIGSEGV段错误信号、SIGINT中断信号）。它的作用是让JVM能正确处理这些信号：比如程序崩溃时生成hs_err_pid日志文件，或者响应你按Ctrl+C的中断请求，本质上是JVM和OS信号系统之间的“翻译官”。

二、为啥它会疯狂占内存还不释放？ #

结合你的场景（Linux、Tomcat8、线程数稳定在300左右），大概率是这几个原因：

• JDK8老版本的已知bug：HotSpot在JDK8早期版本（比如u101之前）存在和JVM_FindSignal相关的内存泄漏问题。这个函数在处理信号时会为线程分配局部存储结构，如果这些结构没有被正确回收，哪怕线程总数稳定，也会随着时间累积大量内存。这类bug在JDK8u202及以后的稳定版本已经被官方修复。
• 线程局部存储（TLS）资源未清理：哪怕你的线程总数保持稳定，若线程复用过程中，TLS里的信号相关资源没有被正确清理，也会导致JVM_FindSignal不断分配新的内存块。
• NMT结果的佐证：你提到NMT报告泄漏位于Internal区域，这个区域正好包含JVM自身的内部内存分配——JVM_FindSignal的分配就属于这个范畴，所以两者的结果完全对应，不存在工具误判的可能。

三、具体的排查和解决方向 #

1. 优先升级JDK版本：这是最直接有效的办法，把你的JDK8升级到u202及以上的稳定版本，多数和JVM_FindSignal相关的内存泄漏bug都已被修复。
2. 排查自定义信号处理逻辑：如果你的应用里有通过JNI或其他方式自定义的信号处理代码，可能和JVM的信号处理机制冲突，导致JVM_FindSignal反复分配资源。先禁用这类自定义逻辑，观察内存变化。
3. 尝试调整JVM参数：可以添加-XX:-UseSignalChaining参数，关闭JVM的信号链处理机制，减少JVM_FindSignal的调用频率。但要注意：这个参数可能会影响JVM崩溃时的日志生成、中断信号响应等功能，务必在测试环境验证后再部署到生产环境。
4. 交叉验证profiling结果：用perf工具再做一次内存采样，确认JVM_FindSignal的内存分配是否真的未释放。比如执行perf record -g -p <你的Tomcat进程PID>，运行数小时后用perf report查看调用链，避免jemalloc的归因偏差。

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