Java-debug

[aibangjuxin]

下面给你一个系统性、可落地的分析与解决方案，完全基于 GKE / Kubernetes 隔离模型 + JVM 诊断机制，并给出推荐的最佳实践，避免你在平台层反复踩坑。

⸻

一、问题分析（为什么 sidecar / kubectl debug + jmap 会失败）

你遇到的现象：

jmap -dump:live,format=b,file=myheap.hprof 8

卡住 / 超时 / 找不到进程

结论先行：

✅ 核心原因就是：进程不共享（PID namespace 不共享）

这是 Kubernetes 的默认安全模型，不是你操作问题。

⸻

1️⃣ Kubernetes 中容器的“进程隔离”真相

Pod ≠ 进程共享（默认）

Namespace 是否默认共享
Network ✅
Volume ✅
PID ❌
IPC ❌

也就是说：

Pod
├── java-app 容器
│ └── PID 8 -> java
└── debug / sidecar 容器
└── PID 8 -> 不存在 / 是另一个进程

👉 jmap attach 的 PID 是“容器视角”的 PID，不是 Pod 级 PID

⸻

2️⃣ jmap / jcmd 的 attach 原理（为什么必须共享 PID）

jmap 并不是“远程工具”，它依赖：
• /proc/
• JVM attach socket（Unix Domain Socket）
• ptrace / SIGQUIT

👉 这些全部要求：
• 在 同一个 PID namespace
• JVM 进程对你“可见”

所以结论是：

❌ 只装了 openjdk ≠ 可以 jmap

✅ 能看到 JVM PID 才是前提

⸻

3️⃣ 为什么 kubectl debug 也不行？

默认 kubectl debug 行为

kubectl debug pod/my-pod -it --image=openjdk

实际发生的是：
• 新增 ephemeral container
• ❌ 不共享 PID namespace
• ❌ 无法 attach JVM

所以结果与 sidecar 完全一样。

⸻

二、如何 100% 验证“进程不共享”这个根因

在 Java 容器中：

ps -ef | grep java
ls -ld /proc/8

在 debug / sidecar 容器中：

ps -ef | grep java
ls -ld /proc/8

你会看到：
• debug 容器中 没有 java
• /proc/8 不存在

👉 这一步是定性证据

⸻

三、可行方案全景图（从“能不能用”到“该不该用”）

方案 是否可行 生产可用 推荐度
sidecar / kubectl debug + jmap ❌ ❌ ❌
shareProcessNamespace ✅ ⚠️ ⚠️
修改 Dockerfile 内置 debug 工具 ✅ ✅ ⭐⭐⭐⭐⭐
Debug 专用镜像 ✅ ✅ ⭐⭐⭐⭐⭐
OOM 自动 HeapDump ✅ ✅ ⭐⭐⭐⭐

⸻

四、推荐的【最佳实践方案】——平台级标准解法

结论：

❌ 不推荐 sidecar / kubectl debug
✅ 推荐 构建 Debug 能力到镜像本身

⸻

✅ 方案一（最推荐）：构建「Debug 版 Java 镜像」

设计思路
• 运行容器本身
• 拥有 jmap / jcmd / jstack
• 不依赖 namespace hack
• 可控、稳定、可 SOP 化

⸻

示例：完整 Dockerfile（生产级）

FROM eclipse-temurin:17-jre-jammy

安装诊断工具（仅 jdk 工具，不是完整 JDK 编译环境）

RUN apt-get update &&
apt-get install -y --no-install-recommends
openjdk-17-jdk-headless
procps
curl
vim
&& rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY app.jar /app/app.jar

ENV JAVA_OPTS="
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp
-XX:+UnlockDiagnosticVMOptions
"

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]

⸻

使用方式

kubectl exec -it pod/java-app -- bash
jps
jmap -dump:live,format=b,file=/tmp/heap.hprof

⸻

为什么这是最佳实践？

维度 优势
稳定性 不依赖 namespace
可控性 工具版本一致
安全 无 ptrace hack
平台化 可做成模板
可审计 镜像即能力

⸻

✅ 方案二：Debug 镜像 + 临时 Deployment（更安全）

架构思路
• 正式镜像：无 debug
• Debug 镜像：有 jmap
• 只在需要时替换 Deployment

kubectl set image deploy/app app=app-debug:latest

👉 这是大厂 SRE 的常见做法

⸻

⚠️ 方案三：shareProcessNamespace: true（不推荐生产）

spec:
shareProcessNamespace: true

问题
• 放大 blast radius
• 容器间可互相 kill
• 破坏隔离模型
• 安全审计难过

👉 只适合实验 / PoC

⸻

五、平台级最佳实践（强烈建议你采纳）

1️⃣ JVM 预埋诊断能力（不等出问题）

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp
-XX:+ExitOnOutOfMemoryError

2️⃣ Heap dump 存储策略

/tmp -> emptyDir -> sidecar -> GCS

或：

kubectl cp pod:/tmp/heap.hprof .

⸻

3️⃣ 明确禁止的做法（写进 SOP）

❌ sidecar jmap
❌ kubectl debug attach JVM
❌ ptrace hack

⸻

六、最终结论（给你一句能直接写进文档的）

在 GKE 中，jmap / jcmd 必须与 JVM 进程处于同一个 PID namespace。
sidecar 与 kubectl debug 默认不共享进程空间，因此 无法用于 JVM heap dump。
唯一稳定、可维护的方案是：将 JVM 诊断工具构建进应用镜像，或使用 Debug 专用镜像。

⸻

如果你需要，我可以下一步帮你：
• 输出 《GKE Java Debug 官方 SOP》
• 或给你一份 平台统一 Java Base Image 规范（prod / debug 双版本）
• 或设计 HeapDump → GCS → 分析工具 的完整链路

[aibangjuxin]

这是一个非常经典的问题。在 Kubernetes (GKE) 环境中，由于容器的隔离特性（Namespace 和 Cgroups），简单的 kubectl debug 往往不足以让 JVM 工具（如 jmap）成功“附着”到目标进程。
以下是深度解析及三种解决方案，从“临时调试”到“生产级标准”。
核心原因分析：为什么 jmap 找不到进程？
即使你在同一个 Pod 里的 sidecar 运行，jmap 失败通常是因为以下三道关卡：

• PID Namespace 隔离：默认情况下，容器间的进程是互相不可见的。如果 ps -ef 看不到 PID 8，jmap 自然找不到。
• /tmp 目录不共享：JVM 的 Attach 机制依赖于 /tmp/.java_pid 这个 Unix Domain Socket 文件。如果两个容器的 /tmp 挂载点不同，jmap 无法与目标 JVM 通信。
• 权限限制 (Capabilities)：jmap 底层使用 ptrace 系统调用。在 GKE 等受限环境中，默认是不允许一个进程 ptrace 另一个进程的。
  方案一：最佳临时调试方案 (kubectl debug 正确姿势)
  不需要修改 Dockerfile，但必须通过正确的参数打破容器壁垒。
  执行步骤
  使用 --target 参数将 debug 容器挂载到业务容器的命名空间中，并共享其文件系统。
  kubectl debug -it <POD_NAME>
  --image=openjdk:11-slim
  --target=<BUSINESS_CONTAINER_NAME>
  -- sh

关键点

• --target: 这一步至关重要！它让 debug 容器进入业务容器的 PID Namespace。
• 用户一致性: 进入后，如果业务进程是以 non-root 运行的，你需要 su 到那个用户，或者使用 chown 修改 dump 文件的权限。
  方案二：修改 Dockerfile (生产环境推荐)
  与其在运行时“硬闯”，不如在构建时“植入”。但不要直接把整个 JDK (几百MB) 塞进去，这会增加攻击面。
  最佳实践：使用多阶段构建 + 必要工具
  仅将调试所需的 jmap, jstat, jcmd 等二进制文件从基础镜像中拷贝出来。
  Dockerfile 示例：

阶段 1: 获取工具

FROM openjdk:11-slim AS debug-tools

阶段 2: 业务镜像

FROM openjdk:11-jre-slim
COPY --from=debug-tools /usr/local/openjdk-11/bin/jmap /usr/local/bin/jmap
COPY --from=debug-tools /usr/local/openjdk-11/bin/jcmd /usr/local/bin/jcmd

注意：jmap 依赖一些 libjvm.so 等库，通常 jre 已经包含了

WORKDIR /app
COPY target/app.jar .

关键：如果生产环境限制了权限，可能需要设置这个

USER 1000

CMD ["java", "-jar", "app.jar"]

方案三：无需 jmap 的“云原生”方案 (最佳实践)
在 GKE 中，最优雅的方式是利用 JVM 自身的诊断能力，避免外部工具的兼容性问题。

1. 利用 jcmd (比 jmap 更现代)
   如果你的 JRE 镜像里有 jcmd，它是首选，因为它对 Attach 机制的容错性更高：
   jcmd GC.heap_dump /tmp/heap.hprof

2. 通过 Java 启动参数自动 Dump
   这是解决“内存溢出后无法现场调试”的最强方案。在 deployment.yaml 中配置：
   env:

• name: JAVA_TOOL_OPTIONS
  value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/oom.hprof"

3. 动态触发 (使用 Arthas)
   Arthas 是阿里开源的诊断工具，它可以通过一个 Java Agent 动态 Attach 到进程，不需要 jmap。

• 下载：curl -O https://arthas.aliyun.com/arthas-boot.jar
• 运行：java -jar arthas-boot.jar
• 在交互界面执行：heapdump /tmp/dump.hprof
  总结与建议
  | 场景 | 推荐方案 | 理由 |
  |---|---|---|
  | 紧急线上排查 | kubectl debug --target=... | 无需重启 Pod，直接进入命名空间。 |
  | 长期运维规范 | Dockerfile 植入 jcmd + Arthas | 工具内置，随时响应，安全受控。 |
  | 防患于未然 | 设置 HeapDumpOnOutOfMemoryError | OOM 发生时的第一手证据，自动捕获。 |
  下一步建议：
  您可以先尝试使用 kubectl debug 加上 --target 参数。如果依然超时，请检查您的 Pod Spec 中是否设置了 shareProcessNamespace: true。需要我帮您编写一个带有该配置的 Deployment 示例吗？

[aibangjuxin]

这是一个非常聪明且符合“云原生”思路的做法。在 Kubernetes/GKE 环境中，通过环境变量（尤其是 JAVA_TOOL_OPTIONS）注入启动参数，是解决 JVM 诊断问题最优雅的“非侵入式”方案。
这种方式可以解决 jmap 无法连接、进程找不到、权限不足等绝大多数调试痛点。以下是详细的实现方案和解决问题的思路：

1. 为什么用 JAVA_TOOL_OPTIONS？
   通常我们无法直接修改 java -jar ... 的启动命令行（因为写死在 Docker 入口或启动脚本中）。
   JAVA_TOOL_OPTIONS 是 JVM 自动识别的一个环境变量。无论你的启动命令是什么，JVM 启动时都会自动将这个变量里的参数合并到启动命令中。
2. 核心场景：通过环境变量解决的问题
   场景 A：解决 OOM 自动捕获 (最推荐)
   如果你的应用是因为内存溢出（OOM）崩溃，此时手动执行 jmap 已经来不及了。

• 注入参数：
  env:

• name: JAVA_TOOL_OPTIONS
  value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/oom-dump.hprof"

• 解决的问题： 当程序发生 OOM 时，JVM 会自动把堆快照写到 /tmp/oom-dump.hprof。你只需要通过 kubectl cp 把文件拿出来即可，不需要任何 jmap 命令。
  场景 B：开启远程调试 (JDWP)
  如果你想在本地用 IntelliJ IDEA 直接 Debug 容器里的代码。
• 注入参数：
  env:

• name: JAVA_TOOL_OPTIONS
  value: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005"

• 解决的问题： 配合 kubectl port-forward 5005:5005，你可以在本地直接打断点。
  场景 C：开启 JMX 监控 (解决 jmap 连不上的终极手段)
  jmap 等工具本质上也是通过协议通信。如果本地 Attach 失败，可以强制开启 JMX 远程管理。
• 注入参数：
  env:

• name: JAVA_TOOL_OPTIONS
  value: "-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

• 解决的问题： 开启后，你可以用本地的 VisualVM 或 JConsole 通过端口转发连接上去进行 Heap Dump。

3. 最佳实践方案：完整实现步骤
   如果你现在想通过这种方式拿一个 Heap Dump，最佳实践流程如下：
   第一步：修改 Deployment 注入环境变量
   修改你的 YAML 或在 GKE 控制台更新环境变量：
   spec:
   template:
   spec:
   containers:
   • name: java-app
     env:
     • name: JAVA_TOOL_OPTIONS
       value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump.hprof"

     建议同时挂载一个 emptyDir 卷到 /tmp，防止容器崩溃后文件丢失

     volumeMounts:
     • name: temp-storage
       mountPath: /tmp
       volumes:
   • name: temp-storage
     emptyDir: {}

第二步：触发 Dump (如果不等 OOM，想手动触发)
既然你已经有了修改权限，最好的办法是结合 Arthas。你不需要把 Arthas 编进镜像，只需要：

• kubectl exec 进入容器。
• 下载 Arthas：curl -O https://arthas.aliyun.com/arthas-boot.jar。
• 运行：java -jar arthas-boot.jar。
• 关键点：由于你注入了正确的 JAVA_TOOL_OPTIONS 或共享了命名空间，Arthas 通常能比 jmap 更轻易地探测到 Java 进程。
• 在 Arthas 内部执行 heapdump /tmp/manual_dump.hprof。
  第三步：将文件拉回到本地
  kubectl cp :/tmp/manual_dump.hprof ./local_dump.hprof

4. 总结：这能彻底解决你的问题吗？
   能！ 相比于在 kubectl debug 里折腾 jmap，修改环境变量注入参数有以下优势：

• 绕过权限痛点：JVM 内部自己 Dump，不需要外部进程通过 ptrace 去“附着”，避开了 Linux 的安全限制。
• 不依赖 JDK 镜像：即便业务镜像只有 JRE，只要注入了参数，JVM 就能自己干活。
• 确定性高：只要 Pod 重启成功，参数必然生效。
  建议： 如果你当前面临的是内存泄漏排查，请立刻注入 -XX:+HeapDumpOnOutOfMemoryError。如果你是想现在就看一眼堆栈，请注入 JMX 参数或者尝试用 Arthas，这比调试 jmap 本身要高效得多。

是的，你的理解非常准确。场景A（利用 JVM 启动参数）确实是目前最简单、最稳健的方式，因为它将“诊断逻辑”直接内化到了 JVM 进程本身。
在这种方式下，你不需要在容器里预装 jmap，也不需要 kubectl debug 这种复杂的 sidecar 操作。
为什么这种方式“更为简单”且有效？

• 内部触发，无需权限：jmap 是从外部通过操作系统指令去“钩” (attach) JVM，会受到 Linux 权限（如 ptrace）和命名空间的限制。而启动参数是让 JVM 在检测到特定情况时自己从内部写文件，这不涉及跨进程通信，成功率几乎是 100%。
• JRE 环境友好：很多精简后的生产镜像（如 openjdk-jre 或 alpine 版）根本没有 JDK 工具。启动参数是 JVM 内核的功能，只要有 Java 运行环境，它就生效。
  如何在不等待 OOM 的情况下手动触发 Dump？
  虽然 HeapDumpOnOutOfMemoryError 非常有用，但如果你想现在立刻拿到 Dump，而又不想折腾 jmap，你可以结合环境变量进行一点点“变形”：
  方案 A+：使用 jcmd (如果镜像里有)
  如果你的环境变量能修改，你可以尝试在 Deployment 的 args 或者是 command 里加入一段逻辑。但更简单的方案是利用你已经有的环境变量权限，加上一个 Arthas。
  方案 A++：终极实践方案（无需 JDK，只需环境变量）
  如果你容器里连 jcmd 都没有，你可以通过注入环境变量开启 JMX。这样你甚至不需要进入容器，直接在你的笔记本上就能拿到 Dump。
• 修改环境变量：
  env:

• name: JAVA_TOOL_OPTIONS
  value: >-
  -Dcom.sun.management.jmxremote
  -Dcom.sun.management.jmxremote.port=9010
  -Dcom.sun.management.jmxremote.local.only=false
  -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false

• 端口转发：
  kubectl port-forward 9010:9010

• 本地操作：
  打开你本地电脑上的 VisualVM 或 JConsole（这是每个 Java 开发者的 JDK 里自带的工具），连接 localhost:9010。在界面上点一下 "Heap Dump" 按钮，文件就会生成。
  这种方式的唯一“代价”
  虽然这种方式简单，但有一点需要注意：

• 需要重启 Pod：修改环境变量会导致 Kubernetes 重新滚动发布（Rolling Update）你的 Pod。如果你的业务对重启非常敏感，请避开高峰期。
  总结你的“免操作”清单：

• 注入环境变量：设置 JAVA_TOOL_OPTIONS（无论是为了 OOM 自动备份，还是为了开启远程 JMX）。

• 确保存储空间：确保 /tmp 目录（或你指定的路径）有足够的磁盘空间来存放 dump 文件（堆有多大，文件就有多大）。

• 拿回文件：使用 kubectl cp 把生成的 .hprof 文件拉回本地分析。
  你想让我帮你写一个完整的、包含 JMX 远程调试参数的 Deployment 修改模板吗？

[aibangjuxin]

既然你的应用程序的问题是频繁重启（CrashLoopBackOff），而且观察到内存持续上升（Memory Leak），那我们必须抢在容器被 Kubernetes 杀死（OOMKilled）之前拿到数据。
在这种情况下，单纯靠 HeapDumpOnOutOfMemoryError 可能拿不到结果，因为：

• K8s 限制（OOMKilled）：当 Pod 达到 resources.limits.memory 时，Linux 内核会直接秒杀进程。此时 JVM 还没反应过来自己 OOM 了，也就来不及写出 .hprof 文件。
• 存活探针（Liveness Probe）：如果内存占用过高导致应用响应变慢，K8s 的探针检测失败也会强制重启容器。
  针对这种**“存活时间有限，且内存不断上涨”**的场景，以下是最佳的分析方案：
  方案一：利用环境变量开启“自动保存” (最简单)
  你可以在环境变量中加入两个关键参数，让 JVM 在被杀掉的一瞬间或退出前尝试留下遗言：
  env:

• name: JAVA_TOOL_OPTIONS
  value: >-
  -XX:+HeapDumpOnOutOfMemoryError
  -XX:HeapDumpPath=/tmp/auto.hprof
  -XX:ErrorFile=/tmp/hs_err_pid%p.log

• ErrorFile：如果是因为 JVM 崩溃重启，这个日志会告诉你崩溃的具体位置（比如是 native 内存溢出还是代码 Bug）。
  方案二：手动触发 + 外部存储 (最有效)
  既然内存是缓慢增长的，你不需要等它死掉。在内存占用达到 80% 左右时，主动手动触发一次 Dump。
  由于你提到的 jmap 连不上，而你又有修改环境变量的权限，强烈建议注入 JMX 参数。

• 修改环境变量重启 Pod：

  • name: JAVA_TOOL_OPTIONS
    value: "-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

• 建立隧道：
  kubectl port-forward 9010:9010

• 实时监控分析：
  使用本地电脑的 VisualVM 连接。

  • 查看垃圾回收（Visual GC）：你可以实时看到是哪个分代（Old Gen）在不停上涨。
  • 主动执行 Dump：在界面上点击 "Heap Dump"。这样你就能拿到一份“内存尚在增长中”的快照，分析到底是什么对象占用了内存不释放。
    方案三：解决文件丢失问题 (关键)
    无论是哪种方式，如果 Pod 重启了，容器内 /tmp 的文件通常会随之消失。要拿到分析结果，你必须保证文件能留下来：
    修改 Deployment 增加临时存储卷：
    spec:
    template:
    spec:
    containers:
    • name: java-app
      volumeMounts:
      • name: dump-dir
        mountPath: /tmp
        volumes:
    • name: dump-dir
      emptyDir: {} # 这样即使容器重启，只要 Pod 没被重排，文件就在

如果 Pod 经常被调度到不同节点，建议将 emptyDir 换成 GKE 的 PersistentVolumeClaim (磁盘)。
方案四：轻量级诊断工具 Arthas (无需重启)
如果你不想频繁修改环境变量重启应用，可以尝试在容器运行期间直接下载 Arthas：

• kubectl exec -it -- sh
• curl -O https://arthas.aliyun.com/arthas-boot.jar
• java -jar arthas-boot.jar
• 进入后执行：
  • dashboard：看一眼整体内存布局。
  • heapdump /tmp/dump.hprof：这就是你要的分析结果。
  • profiler start：生成火焰图，看看到底哪些代码在频繁申请内存。
    总结方案：
    对于你这种内存只增不减导致的重启：
• 第一步：确认 K8s 的 memory limits 是否设得太小。
• 第二步：注入 JMX 环境变量，用本地 VisualVM 连接监控。
• 第三步：在内存高位时，通过 VisualVM 或 Arthas 手动执行 heapdump。
• 第四步：通过 kubectl cp 把文件拿出来，用 MAT (Memory Analyzer Tool) 分析。
  你需要我帮你分析一下如何看懂 MAT 生成的分析报告吗？

[aibangjuxin]

这是一个非常务实且高效的思路：构建一个“诊断增强型”镜像。
既然你现在能修改环境变量，那么在构建 Dockerfile 时顺便把工具集成进去是最稳定的实践。这样你登录 Pod 后，所有命令都能直接运行，不再有权限或路径问题。
以下是完整的实践方案：
第一步：编写“诊断增强”的 Dockerfile
我们将使用多阶段构建。这样你的生产镜像只会增加几十 MB 的诊断工具，而不会带入整个 JDK 源码，保持镜像轻量且安全。

--- 第一阶段：下载/获取工具 ---

FROM alpine:latest AS tool-collector
WORKDIR /tools

下载 Arthas (阿里开源的 Java 诊断神器，比 jmap 强得多)

RUN wget -O arthas-boot.jar https://arthas.aliyun.com/arthas-boot.jar

下载 jmx_prometheus_javaagent (可选，用于导出内存指标到 Prometheus)

RUN wget -O jmx_prometheus_javaagent.jar https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.17.2/jmx_prometheus_javaagent-0.17.2.jar

--- 第二阶段：构建你的业务镜像 ---

假设你原来的镜像基础是 openjdk:11-jre-slim 或类似

FROM openjdk:11-jre-slim

设置中文字符集，防止诊断时日志乱码

ENV LANG C.UTF-8

将第一阶段准备好的工具拷贝进来

COPY --from=tool-collector /tools/arthas-boot.jar /opt/arthas-boot.jar
COPY --from=tool-collector /tools/jmx_prometheus_javaagent.jar /opt/jmx_prometheus_javaagent.jar

关键一步：从 JDK 镜像中拷贝 jmap/jstack 等二进制工具

注意：许多 JRE 镜像其实缺少这些，直接从同版本的 JDK 镜像里拷贝

COPY --from=openjdk:11-slim /usr/local/openjdk-11/bin/jmap /usr/local/bin/jmap
COPY --from=openjdk:11-slim /usr/local/openjdk-11/bin/jstack /usr/local/bin/jstack
COPY --from=openjdk:11-slim /usr/local/openjdk-11/bin/jcmd /usr/local/bin/jcmd
COPY --from=openjdk:11-slim /usr/local/openjdk-11/bin/jstat /usr/local/bin/jstat

业务代码

WORKDIR /app
COPY target/*.jar app.jar

建议：给 /tmp 足够的权限，因为 Java 工具依赖这里存放 Socket 文件

RUN chmod 777 /tmp

ENTRYPOINT ["java", "-jar", "app.jar"]

第二步：结合环境变量（配合你的修改权限）
镜像构建好并部署到 GKE 后，配合你之前提到的环境变量修改权限，注入以下参数：
env:

• name: JAVA_TOOL_OPTIONS
  value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/oom.hprof"

第三步：进入 Pod 进行实战 Debug
当发现内存不断上涨时，你现在的 Pod 已经“全副武装”了，直接执行以下操作：
方法 A：使用 Arthas (推荐，成功率最高)
Arthas 能够自动识别 Java 进程，并提供交互式界面。
kubectl exec -it -- java -jar /opt/arthas-boot.jar

进入后执行：

[arthas@1]$ heapdump /tmp/manual.hprof

方法 B：使用原生 jmap (如果 PID 还是 1)
因为工具已经在 /usr/local/bin 下，且在同一个文件系统，它现在能识别到进程了。
kubectl exec -it -- jmap -dump:live,format=b,file=/tmp/heap.hprof 1

第四步：把 Dump 文件拿出来分析
即便 Pod 随后因为内存问题重启了，只要你提前运行了上述命令，文件就在 /tmp。
kubectl cp :/tmp/manual.hprof ./local_analysis.hprof

最佳实践建议：

• 为什么不只用 jmap？ 因为在容器内，Java 进程通常是 PID 1。有些旧版本的 jmap 在处理 PID 1 时会有 Bug。Arthas 对容器化环境做了大量适配，兼容性更好。
• 关于存储： 既然你观察到的是“内存不断占用”，请确保你的 Pod 声明了足够的磁盘空间（或挂载了 emptyDir），否则 Dump 文件（可能好几个 GB）会直接写满磁盘导致容器崩溃。
• 内存限制调整： 如果 Pod 经常被 K8s OOMKilled，在调试期间可以临时调大 resources.limits.memory。
  你想让我演示一下拿到 .hprof 文件后，如何使用 MAT 工具快速定位到那行“不断增长”的代码吗？