在Linux系统中，PID 1是一个特殊的存在，它是内核启动的第一个进程，也就是我们熟悉的init进程。内核为它赋予了一些普通进程不具备的特殊行为。而在容器技术中，每个容器都有自己独立的PID命名空间，容器内的第一个进程同样占据着PID 1的位置。很多开发者把应用直接作为容器入口运行，看似一切正常，实际上却埋下了信号收不到、僵尸进程堆积等隐患。理解PID 1的责任，并借助tini这类轻量级init工具补齐能力，是编写高质量容器镜像的重要一环。
PID 1 进程在 Linux 中到底特殊在哪里
要理解容器中PID 1的问题，先要回到内核层面看几个特殊机制。第一个特殊点是信号处理。内核对发送给PID 1的信号有默认保护：任何没有显式注册信号处理函数的信号，发送到PID 1时都会被直接忽略。这个设计的初衷是防止init进程被误杀导致系统崩溃，但在容器里就会造成一个常见的坑，比如你执行docker stop时，Docker守护进程会先向容器内的PID 1发送SIGTERM信号，如果应用没有注册对应的处理器，这个信号会被内核直接丢弃，应用根本感知不到停止请求，最终Docker只能等待超时后用SIGKILL强杀，容器从优雅停止变成粗暴终止，正在写入的数据可能因此损坏。
第二个特殊点是僵尸进程收割。在Linux中，子进程退出后并不会立即消失，它会变成僵尸状态，保留退出码等信息等待父进程调用wait()或waitpid()读取。普通情况下，如果一个进程的父进程先退出，这些孤儿进程会被重新挂到PID 1名下，由PID 1负责收割。在容器里，PID 1同样承担这个职责。如果你的应用本身会fork子进程（比如一些脚本调用shell、某些语言的运行时派生工作进程），但自己又没有正确实现收割逻辑，僵尸进程就会在容器里不断累积，占用进程表资源，严重时导致无法创建新进程。
第三个特殊点是电源管理类信号。PID 1是内核电源管理操作的强制依赖，如果容器内PID 1退出了，内核会杀掉该PID命名空间内的所有进程，容器随之终止。这也意味着PID 1是容器生命周期的锚点，它的退出码就是容器的退出码，它的存活状态直接决定容器是否存活。
直接把应用作为 PID 1 运行会产生哪些问题
最典型的问题是信号处理不当。假设你在Dockerfile里写了ENTRYPOINT ["java", "-jar", "app.jar"]，Java应用本身对SIGTERM有默认处理，问题不大；但如果你写的是ENTRYPOINT ["sh", "-c", "java -jar app.jar"]，情况就完全不同了。shell默认不转发信号给子进程，SIGTERM发到sh上被忽略，Java进程毫无感知，容器只能等10秒超时后被SIGKILL杀掉。同理，用shell脚本作为入口时，脚本中启动的最后一条命令如果没有用exec替换shell进程，shell就会一直占着PID 1的位置，信号转发同样失效。
其次是僵尸进程问题。以Python为例，如果你的程序通过subprocess启动子进程，但没有及时调用wait()，子进程退出后会一直处于僵尸状态。在宿主机上这些僵尸最终可能被系统init收走，但在容器的独立PID命名空间里，只有容器内的PID 1能收割它们。如果PID 1就是你的应用本身，而它不具备收割能力，僵尸就永久滞留。可以通过docker exec进入容器执行ps aux观察，如果看到大量状态为Z的进程，基本可以确认是这个问题。
再者是一些库对PID 1的兼容性缺陷。某些程序在检测到自己成为PID 1时会有异常行为，比如早期版本的某些JVM版本、一些多进程模型的框架，在PID 1位置上运行会出现意外崩溃或行为异常。另外，进程作为PID 1运行时，权限和信号相关的默认行为也会与普通进程不同，这些差异往往难以提前预知，只能通过实际测试暴露。
tini 的原理与使用方法
tini是一个专为容器设计的轻量级init程序，C语言编写，编译后只有几十KB，几乎不消耗资源。它的核心职责有三项：一是启动时把你指定的命令作为子进程运行；二是正确注册并转发所有信号给子进程，保证docker stop时应用能收到SIGTERM实现优雅退出；三是持续收割容器内的僵尸进程，包括孙进程级别的孤儿，全部回收干净；四是子进程退出时，tini也跟着退出，并把子进程的退出码作为自己的退出码返回，保证容器退出码语义正确。
使用tini最标准的方式是在Dockerfile中集成。下面是一个典型示例，多阶段构建中在第一阶段编译tini，第二阶段把它复制到镜像的固定路径并设为入口：
# ---------- 阶段一：编译tini ----------
FROM golang:1.22-alpine AS builder
RUN apk add --no-cache git cmake make gcc musl-dev
RUN git clone https://github.com/krallin/tini.git /tmp/tini \
&& cd /tmp/tini \
&& cmake . && make
# ---------- 阶段二：运行业务镜像 ----------
FROM openjdk:17-jdk-alpine
# 从构建阶段复制编译好的tini二进制
COPY --from=builder /tmp/tini/tini /usr/bin/tini
# 固定入口为tini，tini再启动java
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["java", "-jar", "/app/app.jar"]
其中--表示tini后续的参数就是要运行的命令。也可以直接使用alpine镜像自带的tini包，执行apk add --no-cache tini安装后设置ENTRYPOINT ["/sbin/tini", "--"]即可，无需自己编译。此外，Docker从1.13版本开始内置了类似功能，执行docker run --init启动容器时，Docker会自动在容器内挂载一个自带的tini作为PID 1，无需修改镜像，非常适合临时验证或无法改动镜像的场景。
在Kubernetes环境中，还可以通过Pod的shareProcessNamespace或容器运行时配置实现类似效果，但对于简单场景，在镜像层面用tini是最直接、最可控的方案。需要注意的一点是，如果使用shell脚本作为入口，即使加了tini，脚本内部启动主进程时仍建议使用exec，例如exec java -jar app.jar，这样可以让java直接替换shell进程成为tini的子进程，信号链路更短，转发更及时。
验证与排查：如何确认容器信号处理是否正常
验证信号处理是否正常很简单。启动容器后执行docker stop -t 60 容器名，同时用time计时，如果容器在一两秒内就停止，说明SIGTERM被正确接收并处理；如果每次都要等满超时时间才停，基本可以断定信号没有被处理。也可以从应用侧验证，在代码里注册SIGTERM处理器，打印一行日志后执行清理逻辑再退出，观察日志是否出现。
# 计时观察容器停止耗时，判断SIGTERM是否生效
time docker stop myapp
# 进入容器检查僵尸进程
docker exec myapp ps aux | awk '$8 ~ /Z/ {print}'
# 查看容器内进程树，确认PID 1是谁
docker exec myapp ps -ef
docker top myapp
排查僵尸进程时，重点看两处：一是ps aux输出中STAT列带Z的进程数量是否随时间增长；二是进程树结构中是否存在已经退出但父进程未回收的中间进程。引入tini后，僵尸进程会被统一挂到tini名下并即时收割，进程树会干净很多。
总结来说，容器内的PID 1不是一个可以随意对待的角色，信号转发、僵尸收割、退出码传递这三项责任缺一不可。与其在应用代码里费力实现完整的init逻辑，不如直接引入tini这种久经考验的方案，配合exec的正确用法和docker stop超时时间的合理设置，就能让容器的启停行为完全符合预期，这也是生产级容器镜像的基本素养。