htop树状视图分析容器进程需先按f5切树形，再添加cgroup列识别控制组边界，结合cpu%/res/%mem等资源列判断是否受cgroup限制。
用 htop 的树状视图分析多层级容器化进程，关键在于看清进程父子关系、识别 Cgroup 边界、结合资源列判断是否受限制。它不是单纯看“谁占得多”，而是看“谁在哪个控制组里、有没有被压着跑”。
打开树状视图并确认容器进程结构
启动 htop 后按 F5（或 t）切换为树状模式。容器化环境（如 Docker、Podman 或 YARN 容器）通常表现为清晰的层级：
- 根节点常见为
systemd、containerd或dockerd - 往下一级通常是容器运行时进程，例如
containerd-shim或podman - 再下一级是容器 init 进程（如
/pause、sh、java），及其子线程或子进程
若某 Java 应用在 Kubernetes Pod 中运行，你可能看到：
containerd─┬─containerd-shim─┬─pause<br> │ └─java───23*[{java}]
这说明全部 23 个线程都归属该容器进程树，资源占用应整体评估。
识别 Cgroup 边界与资源限制痕迹
Linux 内核通过 Cgroup 实现容器资源隔离，但 htop 默认不显示 cgroup 路径。需手动添加列来辅助判断：
- 按 F2 → “Columns” → “Available columns” 中找到
CGROUP或CGROUPS，用空格选中并移到右侧 → “Press Enter to save” - 返回主界面后，新增一列显示该进程所属的 cgroup 路径，例如：
/kubepods/burstable/pod-xxx/java或/docker/abc123... - 同一路径下的所有子进程，共享 CPU 配额、内存上限等约束；若某子进程
%MEM很高但父进程整体未超限，说明内存限制可能设得偏松
结合资源列交叉验证是否触发限制
仅看树形结构不够，要联动观察数值异常点：
-
CPU% 突然归零或卡在低值：可能是被 CFS bandwidth 限制（
cpu.cfs_quota_us / cpu.cfs_period_us配置过严），即使就绪队列有任务也无法调度 -
RES 高但 SHR 低、VIRT 极大：提示进程大量分配私有内存，若其 cgroup 内存上限（
memory.max）已接近RES，OOM Killer 可能随时介入 -
同一树下多个子进程 MEM% 总和远超 100%：正常（百分比按总物理内存计算），但若它们共属一个 2G 内存限制的 cgroup，而
RES总和达 2.1G，就已越界
快速定位越界或异常容器的实操步骤
当系统报警内存或 CPU 持续高位时：
- 先按 F5 进入树状视图，找最宽的分支（通常对应活跃容器）
- 按 F4 输入关键词过滤，如
java、python、node或容器 ID 前缀 - 选中父进程（如
java行），按 Shift+T 展开全部子线程（确保没遗漏僵尸线程） - 按 M 按内存排序，观察顶部几个进程是否同属一个 cgroup 路径；若分散在不同路径，说明资源争抢来自多个容器
不复杂但容易忽略：树状视图本身不显示限制值，但它把“谁和谁被绑在一起管”这件事变得一目了然——这才是分析容器资源归属的第一步。
