Apache error_log 不记录 Java OOM 错误，因其与 JVM 是分离进程；OOM 由 JVM 或应用服务器（如 Tomcat 的 catalina.log）记录，error_log 仅显示代理连接异常等间接征兆。
Apache 的 error_log 本身不直接记录 Java 内存分配失败（如 java.lang.OutOfMemoryError），因为 Apache HTTP Server（C 实现）和 Java 应用（如 Tomcat、Jetty）是分离的进程。真正发生内存分配失败的是 Java 虚拟机（JVM），其日志由 JVM 自身或应用服务器生成，而非 Apache 的 error_log。
为什么 error_log 通常不包含 Java OOM 信息
Apache HTTP Server 主要处理 HTTP 请求分发、静态资源服务、反向代理等。当它与 Java 应用配合（例如通过 mod_proxy_ajp 或 mod_proxy_http 代理到 Tomcat），它只关心后端是否响应、连接是否超时、返回状态码是否异常。即使 Java 端已崩溃或抛出 OutOfMemoryError，Apache 通常只记录类似以下内容：
[proxy:error] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s[proxy_http:error] AH01114: HTTP: failed to make connection to backend: localhost[proxy:error] AH00898: Error reading from remote server returned by /app/xxx
这些是**间接征兆**——说明后端（Java 进程）可能无响应、已退出或拒绝新连接，但不是内存问题的直接证据。
真正需要检查的日志位置
要定位 Java 内存分配失败，应优先查看：
立即学习“Java免费学习笔记（深入）”；
-
JVM 垃圾回收日志（启用
-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps）：观察 Full GC 频率飙升、老年代持续接近 100%、GC 后内存无法释放等现象。 -
Tomcat 的 catalina.out 或 logs/catalina.log：
OutOfMemoryError异常堆栈会完整输出在此，例如：
java.lang.OutOfMemoryError: Java heap space 或 java.lang.OutOfMemoryError: Metaspace。 - JVM Crash 日志（hs_err_pid*.log）：若 JVM 因严重错误（如本地内存耗尽、JIT 崩溃）挂掉，该文件会包含线程快照、内存映射和错误原因。
Apache error_log 中可辅助判断的间接线索
尽管不直接，但以下模式在排除网络/配置问题后，可提示 Java 后端健康恶化，值得结合 JVM 日志交叉验证：
- 大量 “Connection refused” 或 “Connection reset by peer”：尤其集中在某段时间，可能因 JVM 停顿过长（如长时间 Full GC）导致 accept 队列溢出或连接被内核重置。
-
代理超时集中爆发：如大量
ProxyTimeout或Read timeout错误，且对应 Java 应用响应时间监控同步升高，暗示 JVM STW 时间过长或线程池耗尽。 - worker 被频繁禁用（disabling worker）：说明后端连续失败（如健康检查失败），而健康检查失败常源于应用无响应——内存问题是最常见原因之一。
实用建议：建立可观测性闭环
不要依赖 error_log 单点排查 Java 内存问题。推荐做法：
- 为 Java 进程启用详细 GC 日志 +
-XX:+HeapDumpOnOutOfMemoryError，确保 dump 文件路径有写入权限。 - 在 Apache 代理配置中开启
ProxyStatus On，并通过/server-status?auto实时观察后端 worker 状态、请求排队、失败计数。 - 部署基础监控（如 Prometheus + JMX Exporter），采集 JVM 内存各区使用率、GC 时间、线程数；设置告警阈值（如老年代 >95% 持续 2 分钟）。
- 将 Apache error_log 中的后端错误（如 proxy:error）与 Java 应用日志按时间窗口对齐分析，确认是否共发。
