Java8官方文档称hs_err_pid无法写入当前目录时存/tmp，实测未生成

官方文档描述不存在偏差，该问题是容器场景下多个易被忽略的环境特性/配置遗漏导致，常见原因及排查方向如下：

• 优先检查JVM工作目录下的文件：未配置-XX:ErrorFile参数时，JVM会优先将崩溃日志写入进程启动时的工作目录，仅当工作目录不可写时才会 fallback 写入/tmp。可执行ls -l /proc/<JAVA_PID>/cwd查看Java进程的实际工作目录路径，检查该路径下是否存在对应hs_err文件，同时确认该目录的写入权限正常。
• 确认Java进程是否为容器内PID 1进程：Linux内核默认对PID 1进程做特殊信号处理，PID 1进程收到SIGSEGV（即kill -11触发的信号）时不会执行默认的信号处理逻辑，会直接终止，导致JVM的崩溃日志生成流程未被触发。如果Java进程是容器入口直接启动的PID 1进程，可在启动命令前加exec，或使用tini等轻量init进程作为容器入口，将Java进程作为子进程启动即可规避该问题。
• 排查JVM启动参数的隐含配置：部分裁剪版JDK镜像会默认添加-XX:+SuppressFatalErrorMessage参数，该参数会直接禁用hs_err日志的生成；另外也需确认是否存在-XX:ErrorFile=/dev/null这类将日志指向空设备的隐藏配置，可执行cat /proc/<JAVA_PID>/cmdline查看完整的启动参数。
• 排查容器生命周期导致的日志丢失：如果Java进程崩溃后触发了Pod/容器重启而非进程原地重启，容器重启后原根文件系统的所有内容（包括/tmp下的文件）都会被清空，自然无法找到生成的日志。可调整测试方式，在触发崩溃前同时监听工作目录和/tmp下的文件变动，避免日志被重启动作清掉。
• 排查集群安全策略限制：如果集群配置了Seccomp、AppArmor或自定义Pod安全策略，可能会限制进程生成新文件的行为，尤其是对/tmp目录做了只读挂载、noexec限制的场景，可检查Pod的volume挂载配置和安全策略规则。

内容的提问来源于stack exchange，提问作者David M. Karr