nginx 不运行 java，仅作反向代理；内存泄漏须分层检测：nginx 侧用 valgrind、日志及 pmap 查 worker 进程，java 侧用 jstat/jmap/mat 查 jvm 堆，二者工具与指标不可混用。
这个问题本身存在概念混淆：Nginx 本身是用 C 编写的 Web 服务器，不直接运行 Java 字节码；它和 Java 应用的常见协作方式是作为反向代理（如将请求转发给后端 Tomcat、Spring Boot 内嵌容器等）。因此，“Nginx 中 Java 部署”实际指的是 Nginx + Java 后端服务 的联合架构。内存泄漏检测必须分层进行——Nginx 侧查自身 worker 进程泄漏（C 层），Java 侧查后端 JVM 泄漏（Java 层），二者不能混用工具，也不能互相替代。
明确分工：Nginx 和 Java 各自的检测边界
Valgrind 对 Nginx 有效，但对 Java 进程无效（JVM 管理堆内存，绕过 malloc/free）；jstat/jmap/MAT 对 Java 有效，但无法分析 Nginx 的 ngx_pool_t 分配行为。必须分开排查：
-
Nginx 层：关注 worker 进程 RSS 持续上涨、频繁重启、error.log 中出现
malloc(): out of memory或ngx_palloc: failed等日志 -
Java 层：关注老年代（Old Gen）使用率持续 >85%、Full GC 后内存不回落、GC 时间占比突增（>90%）、
java.lang.OutOfMemoryError: Java heap space - 若 Nginx 日志中大量出现
upstream timed out或502 Bad Gateway，而 Java 进程已卡死或 OOM，说明问题在 Java 侧，Nginx 只是“受害者”
Java 后端内存泄漏检测实操步骤
假设 Java 应用部署在 8080 端口，Nginx 通过 proxy_pass http://127.0.0.1:8080 转发流量：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 确认 Java 进程 PID：
ps aux | grep java | grep 8080 - 实时盯 GC 行为：
jstat -gcutil <pid> 2000</pid>，重点看O（老年代使用率）是否单向爬升、FGC是否密集且回收量小 - 主动抓堆快照（勿等 OOM）：
jmap -dump:live,format=b,file=heap.hprof <pid></pid> - 用 MAT 打开
heap.hprof→ 查 “Leak Suspects Report” → 点击可疑对象 → “Path to GC Roots”（排除 weak/soft）→ 定位到 static 缓存、未关闭的 Closeable、ThreadLocal 残留等 - 补充验证：用
curl -X GET http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:old（如启用 Spring Boot Actuator）确认指标趋势
Nginx 侧需同步排查的干扰项
即使泄漏在 Java 层，Nginx 配置不当也会放大问题表现，需快速排除：
- 检查
proxy_buffering off;—— 若开启且后端响应慢，Nginx 会缓存大响应体，占用额外内存 - 确认
proxy_buffers和client_max_body_size是否过大（如设为 128m），避免单请求耗尽 worker 内存 - 禁用所有非必要第三方模块（尤其含 Lua 或 C 自定义逻辑的），用
nginx -t验证配置，再逐个启用测试 - 运行
pmap -x <worker-pid> | tail -n 20</worker-pid>查看内存映射，确认是否存在异常大的匿名映射段（疑似未释放 mmap）
协同定位技巧：用请求链路串联两层
当某类请求（如上传接口、报表导出）触发内存问题时，可建立关联线索：
- 在 Nginx access_log 中开启
$request_time和$upstream_response_time，筛选响应时间超长的请求路径 - 在 Java 应用中对该路径添加日志埋点，记录进入/退出时间、关键对象创建数、缓存 size 变化
- 用
arthas trace监控该接口方法调用栈，看是否有循环添加、未 close 的流或连接 - 若发现某次请求后 Java 堆增长 +100MB 且不回收，同时对应 Nginx worker RSS 上涨 50MB，基本锁定该业务逻辑为泄漏源头
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
