检测Java内存泄漏应监控Tomcat进程而非Apache httpd，通过jps定位PID，配置JVM参数启用GC日志与OOM堆转储，用jstat观察老年代使用率，OU达75%–85%时用jmap -dump:live抓取有效堆转储，再用MAT分析Leak Suspects、膨胀类及GC Roots强引用链，重点排查ThreadLocal、静态集合、未注销监听器、Filter引用、连接池泄露及日志框架绑定等Tomcat特有泄漏点。
Apache 本身不运行 Java，你实际部署的是 Java Web 应用（如 Spring Boot、Servlet 项目），它运行在 Apache Tomcat（或 Jetty、Undertow）这类 Servlet 容器中。而 Tomcat 常被反向代理到 Apache HTTP Server（httpd）前端，但内存泄漏发生在 JVM 层，所以检测对象是 Tomcat 进程，不是 Apache httpd 进程。
确认 Tomcat 进程并启用基础监控
先定位真实 Java 进程：
- 执行 jps -l 或 ps aux | grep tomcat，找到类似
/path/to/tomcat/bin/bootstrap.jar的进程 PID - 确保 JVM 启动时已添加必要参数（推荐加在
setenv.sh或catalina.sh中）：- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/tomcat/dumps/（OOM 时自动保存快照）
- -XX:+PrintGCDetails -Xloggc:/opt/tomcat/logs/gc.log -XX:+PrintGCDateStamps（记录 GC 行为）
- 生产环境慎用
-agentlib:jdwp，调试阶段可临时开启远程调试
用 JDK 工具实时盯住老年代趋势
不等 OOM，早发现异常增长：
- 运行 jstat -gcutil <pid> 2000，每 2 秒刷新一次，重点关注：
- OU（Old Used %）是否持续 >90% 且不回落
- FGC（Full GC 次数）是否陡增，但每次回收量极小（如 OU 只降 1–2%）
- 对比 jstat -gccapacity <pid> 看老年代实际容量是否被长期占满
- 若确认趋势异常，立即进入下一步抓取，避免等到服务卡死
在内存高位时主动抓取有效堆转储
OOM 后 dump 已失真，应在 OU 达 75%–85% 且稳定上升时触发：
立即学习“Java免费学习笔记（深入）”；
- 用 jmap -dump:live,format=b,file=tomcat-heap-$(date +%s).hprof <pid>
（
live参数关键：只导出可达对象，排除 GC 暂未清理的“僵尸”） - 若 jmap 响应慢或失败，改用 VisualVM 远程连接 Tomcat（需提前在
catalina.sh加-Dcom.sun.management.jmxremote=...），直接点 “Heap Dump” 更稳定 - 注意权限：确保运行 jmap 的用户对 Tomcat 进程有 ptrace 权限（Linux 上可能需
sudo -u tomcat jmap ...）
用 MAT 分析转储定位泄漏源
打开 .hprof 文件后聚焦三步：
- 先看 Leak Suspects Report —— MAT 自动标出占用最大内存的 1–3 个嫌疑对象（例如：static final ConcurrentHashMap 占 68%）
- 进对应类 → 点 “Group by Package” 或 “Classes”，找实例数异常膨胀的类（如某 Controller 内部类实例达 10 万+）
- 选一个典型实例 → 右键 “Paths to GC Roots → exclude all except strong refs”
查看谁在强引用它：常见结果包括
- ThreadLocalMap.value（线程池复用导致 ThreadLocal 未清理）
- java.util.logging.Logger.handlers（自定义 Handler 未注销）
- org.apache.catalina.loader.WebappClassLoader（热部署残留类加载器，连带整个应用类）
- static 字段持有的 List/Map/Cache（尤其 Spring 单例 Bean 中的静态集合）
结合 Tomcat 特性缩小排查范围
Web 容器场景下高频泄漏点更具体：
-
监听器未注销：ServletContextListener 创建的全局资源（如定时任务、缓存监听）未在
contextDestroyed()中清理 -
Filter/Servlet 实例泄漏：自定义 Filter 持有 request/session 引用，或未实现
destroy() -
JDBC 连接池未关闭：Druid/Hikari 配置了
maxLifetime但未设removeAbandonedOnBorrow，连接泄露拖垮堆 -
日志框架绑定：Logback 的
LoggerContext被 WebappClassLoader 加载，重启后旧 context 未释放 - 验证方式：重启 Tomcat 后观察内存是否归零；若仍高，说明类加载器级泄漏已发生
