233｜容器化 Java 应用调优：CPU内存限额、JVM感知、优雅停机和镜像优化

# 物理机部署：32 核 64GB，JVM 设置 -Xmx48g，一切正常
# 容器部署：限制 2 核 2GB，JVM 仍然认为自己有 32 核 64GB
# 结果：JVM 开了 32 个 GC 线程争抢 2 个 CPU，堆内存默认 16GB 远超容器限制
# Pod 启动后 30 秒被 OOM Killer 杀死

# Pod 定义
resources:
  limits:
    cpu: "2"
    memory: "2Gi"
  requests:
    cpu: "1"
    memory: "1Gi"

# 现代 JVM 的容器感知参数（JDK 10+）

- XX:+UseContainerSupport          # 启用容器感知（默认开启）


- XX:MaxRAMPercentage=75.0         # 最大堆内存占容器内存的百分比（替代 -Xmx）


- XX:InitialRAMPercentage=25.0     # 初始堆内存占容器内存的百分比（替代 -Xms）


- XX:MinRAMPercentage=50.0         # 小内存场景（<200MB）的堆内存百分比

# 坏做法：硬编码 -Xmx
java -Xmx1500m -jar app.jar   # 容器限制 2GB，看似合理
# 但运维改了容器限制为 4GB，代码没改，JVM 还是只用 1.5GB

# 好做法：百分比
java -XX:MaxRAMPercentage=75.0 -jar app.jar
# 容器 2GB → 堆 1.5GB，容器 4GB → 堆 3GB，自动适应

# JDK 10+ 的默认值

- XX:MaxRAMPercentage=25.0    # 默认只给堆 25%！这太保守了


- XX:MinRAMPercentage=50.0

# 方法1：查看 JVM 启动参数
java -XX:+PrintFlagsFinal -version | grep -E "UseContainerSupport|MaxRAMPercentage|InitialRAMPercentage"

# 方法2：在容器内运行
docker run --memory=2g --cpus=2 my-java-app java -XX:+PrintFlagsFinal -version | grep MaxHeapSize

# 方法3：使用 jinfo（运行时查看）
jinfo -flag MaxHeapSize <pid>
# 在 2GB 容器中，MaxHeapSize 应该约为 1.5GB（如果 MaxRAMPercentage=75）

cpu.cfs_period_us = 100000（100ms，默认调度周期）
cpu.cfs_quota_us  = 200000（200ms，每周期可用的 CPU 时间）

// JVM 内部逻辑
int availableProcessors = Runtime.getRuntime().availableProcessors();
// 物理机 32 核 → 返回 32
// 容器限制 2 核 → 返回 2（JDK 10+）

# 如果容器感知不生效，可以手动指定

- XX:ActiveProcessorCount=2

# 查看容器的 CPU 限流情况
cat /sys/fs/cgroup/cpu/cpu.stat
# nr_periods: 1000    ← 经历了 1000 个调度周期
# nr_throttled: 200   ← 其中 200 个周期被限流
# throttled_time: 50000000000  ← 总限流时间（纳秒）

# 如果 nr_throttled / nr_periods > 10%，说明 CPU 配额不足

┌─────────────────────────────────────────────────────────────┐
│                    容器内存限制（如 2GB）                     │
├─────────────────────────────────────────────────────────────┤
│ ┌───────────────────────────────────────────────────────┐   │
│ │                    堆内存 (Heap)                       │   │
│ │  -Xmx / MaxRAMPercentage                              │   │
│ │  存放：对象实例、数组                                   │   │
│ └───────────────────────────────────────────────────────┘   │
│ ┌──────────────────────────────┐ ┌────────────────────────┐ │
│ │      元空间 (Metaspace)       │ │    线程栈 (Thread Stack) │ │
│ │  -XX:MaxMetaspaceSize        │ │  -Xss (默认 1MB/线程)    │ │
│ │  存放：类元数据、方法信息      │ │  存放：局部变量、调用栈   │ │
│ └──────────────────────────────┘ └────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────┐   │
│ │              堆外内存 (Direct Memory)                  │   │
│ │  -XX:MaxDirectMemorySize（默认等于 -Xmx）              │   │
│ │  存放：NIO ByteBuffer、Netty 池化内存                   │   │
│ └───────────────────────────────────────────────────────┘   │
│ ┌───────────────────────────────────────────────────────┐   │
│ │              其他 (Code Cache / GC / JIT / Native)     │   │
│ │  Code Cache、GC 数据结构、JIT 编译器、JNI 调用          │   │
│ └───────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

容器内存 = 堆 + 元空间 + (线程数 × 线程栈大小) + 堆外内存 + 其他

# 现象：容器被 OOM Kill，但 Heap Dump 只有 500MB，容器限制 2GB
# 诊断思路：
# 1. 查看 JVM 进程的 RSS（实际物理内存）
ps -o rss,vsz,cmd -p <pid>
# 2. 使用 Native Memory Tracking
java -XX:NativeMemoryTracking=detail -jar app.jar
jcmd <pid> VM.native_memory summary
# 3. 排查 Netty 堆外内存（常见元凶）
# 检查是否有 ByteBuf 未释放

# 一个线程默认栈大小 1MB，1000 个线程 = 1GB 栈内存
# 如果容器只有 2GB，线程栈就可能吃掉一半
# 诊断：
jstack <pid> | grep "^\"" | wc -l   # 统计线程数
# 如果线程数 > 500，考虑减少线程池大小或降低 -Xss

# 现象：java.lang.OutOfMemoryError: Metaspace
# 常见原因：动态生成大量类（CGLIB 代理、Groovy 脚本、JSP 编译）
# 解决：

- XX:MaxMetaspaceSize=256m   # 设置上限


- XX:+PrintClassHistogram    # 查看类加载情况

# 通用容器化 Java 应用 JVM 参数（JDK 11+）
java \
  -XX:MaxRAMPercentage=75.0 \
  -XX:InitialRAMPercentage=25.0 \
  -XX:MaxMetaspaceSize=256m \
  -XX:MaxDirectMemorySize=256m \
  -Xss512k \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 \
  -XX:+ExitOnOutOfMemoryError \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/tmp/heapdump.hprof \
  -jar app.jar

# 参数说明：
# MaxRAMPercentage=75  → 堆占容器内存 75%
# MaxMetaspaceSize     → 防止元空间无限制增长
# MaxDirectMemorySize  → 防止堆外内存无限制增长
# Xss512k              → 减少线程栈大小（默认 1MB，降到 512KB）
# ExitOnOutOfMemoryError → OOM 时直接退出，让 K8s 重启
# HeapDumpOnOutOfMemoryError → OOM 时保留现场

1. Pod 状态变为 Terminating
2. PreStop Hook 执行（如果定义了）
3. 向容器主进程发送 SIGTERM 信号
4. 等待 terminationGracePeriodSeconds（默认 30 秒）
5. 如果进程仍未退出，发送 SIGKILL 强制杀死

// 默认情况下，JVM 不会自动处理 SIGTERM
// 进程被直接杀死，正在处理的请求丢失，连接池未关闭

# application.yml
server:
  shutdown: graceful

spring:
  lifecycle:
    timeout-per-shutdown-phase: 20s

// 或者通过代码
@SpringBootApplication
public class Application {

    public static void main(String[ ] args) {

        SpringApplication app = new SpringApplication(Application.class);
        app.setRegisterShutdownHook(true);  // 注册 JVM Shutdown Hook
        app.run(args);
    }
}

1. 收到 SIGTERM
2. 健康检查端点返回 OUT_OF_SERVICE（K8s 停止转发流量）
3. 等待正在处理的请求完成（最多 timeout-per-shutdown-phase）
4. 关闭线程池
5. 关闭数据库连接池
6. 关闭消息队列消费者
7. 清理临时文件
8. 进程退出

apiVersion: v1
kind: Pod
spec:
  terminationGracePeriodSeconds: 60   # 给足时间（必须 > Spring 超时时间）
  containers:
  - name: java-app
    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sh
          - -c
          - |
            # 1. 通知负载均衡停止路由流量
            curl -X POST http://localhost:8080/actuator/shutdown
            # 2. 等待流量排空（取决于 LB 刷新间隔）
            sleep 15

terminationGracePeriodSeconds > PreStop sleep + Spring timeout-per-shutdown-phase + 缓冲
推荐：60 = 15 (PreStop) + 20 (Spring) + 25 (缓冲)

// 某些框架（如旧版 Netty）会忽略 SIGTERM
// 解决：使用 -XX:+ExitOnOutOfMemoryError 或自定义 Signal Handler
sun.misc.Signal.handle(new sun.misc.Signal("TERM"), signal -> {
    System.out.println("Received SIGTERM, shutting down...");
    SpringApplication.exit(context, () -> 0);
});

// 错误做法：线程池没有在 shutdown hook 中关闭
ExecutorService executor = Executors.newFixedThreadPool(10);
// 正确做法：使用 @PreDestroy 或 Shutdown Hook
@PreDestroy
public void shutdown() {
    executor.shutdown();
    executor.awaitTermination(10, TimeUnit.SECONDS);
}

// HikariCP 默认会在 shutdown hook 中关闭连接池
// 但如果你自定义了 DataSource，需要手动处理
@Bean(destroyMethod = "close")
public DataSource dataSource() {
    return new HikariDataSource(config);
}

# ===== 阶段 1：构建阶段 =====
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
# 先下载依赖（利用 Docker 缓存层）
RUN mvn dependency:go-offline -B
COPY src/ src/
RUN mvn package -DskipTests

# ===== 阶段 2：运行阶段 =====
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

# 创建非 root 用户
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# 仅复制 JAR 包
COPY --from=builder /app/target/*.jar app.jar

USER appuser

ENTRYPOINT ["java", \
  "-XX:MaxRAMPercentage=75.0", \
  "-XX:+UseG1GC", \
  "-XX:+ExitOnOutOfMemoryError", \
  "-jar", "app.jar"]

# 使用 jlink 创建定制 JRE
FROM eclipse-temurin:17-jdk-alpine AS jlink-builder
# 分析依赖，找出需要的模块
RUN jdeps --ignore-missing-deps -q \
    --recursive \
    --multi-release 17 \
    --print-module-deps \
    --class-path 'app/lib/*' \
    app.jar > modules.txt

# 用 jlink 创建精简 JRE
RUN jlink \
    --add-modules $(cat modules.txt) \
    --strip-debug \
    --no-man-pages \
    --no-header-files \
    --compress=2 \
    --output /jre

# 最终镜像
FROM alpine:3.19
COPY --from=jlink-builder /jre /opt/jre
COPY --from=builder /app/target/app.jar /app/app.jar
ENV JAVA_HOME=/opt/jre
ENV PATH="/opt/jre/bin:${PATH}"
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

<!-- pom.xml -->
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <layers>
            <enabled>true</enabled>
        </layers>
    </configuration>
</plugin>

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

# 按变更频率从低到高复制各层
COPY --from=builder /app/target/dependencies/ ./
COPY --from=builder /app/target/spring-boot-loader/ ./
COPY --from=builder /app/target/snapshot-dependencies/ ./
COPY --from=builder /app/target/application/ ./

ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

# 部署配置
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: order-service
        image: order-service:latest  # 850MB
        resources:
          limits:
            cpu: "2"
            memory: "2Gi"
          requests:
            cpu: "1"
            memory: "1Gi"

# JVM 参数（原始）
java -Xmx1500m -Xms1500m -jar order-service.jar

# 优化前：单阶段构建，镜像 850MB
FROM openjdk:11
COPY target/order-service.jar /app/
ENTRYPOINT ["java", "-Xmx1500m", "-Xms1500m", "-jar", "/app/order-service.jar"]

# 优化后：多阶段 + 分层 + 精简 JRE
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src/ src/
RUN mvn package -DskipTests
RUN java -Djarmode=layertools -jar target/*.jar extract

FROM eclipse-temurin:17-jre-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /app/dependencies/ ./
COPY --from=builder /app/spring-boot-loader/ ./
COPY --from=builder /app/snapshot-dependencies/ ./
COPY --from=builder /app/application/ ./
USER app
ENTRYPOINT ["java", \
  "-XX:MaxRAMPercentage=60.0", \
  "-XX:MaxMetaspaceSize=128m", \
  "-XX:MaxDirectMemorySize=256m", \
  "-Xss512k", \
  "-XX:+UseG1GC", \
  "-XX:+ExitOnOutOfMemoryError", \
  "-XX:+HeapDumpOnOutOfMemoryError", \
  "org.springframework.boot.loader.JarLauncher"]

spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: order-service
    image: order-service:optimized
    resources:
      limits:
        cpu: "2"
        memory: "3Gi"    # 从 2Gi 增加到 3Gi
      requests:
        cpu: "1"
        memory: "2Gi"
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 15"]
    readinessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10

server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 25s