Java 应用生产环境启动参数强制规范

1. 规范目的

消除因环境差异（OS版本、Docker/物理机、JDK厂商）导致的时间偏移、乱码、随机数阻塞及 OOM 无法排查等隐患，确保应用行为的确定性（Determinism）。

2. 核心原则

1. 显式优于隐式：不依赖 OS 的 /etc/localtime 或 LANG 环境变量。
2. 位置决定命运：所有 -D 参数必须位于 -jar 之前。
3. Fail-Fast：配置错误应在启动时报错，而不是运行时由于逻辑错误崩溃。

---

3. 标准化参数详解 (The Golden List)

所有 Java 生产环境应用（SpringBoot/Tomcat/Jar）必须包含以下核心参数组。

3.1 强制性基础参数 (必须配置)

# 1. 时区定义 (彻底解决时间漂移)
-Duser.timezone=Asia/Shanghai

# 2. 编码定义 (解决日志与文件名乱码)
-Dfile.encoding=UTF-8
-Dsun.jnu.encoding=UTF-8

# 3. 服务器模式 (禁止图形化调用)
-Djava.awt.headless=true

# 4. 随机数熵池优化 (解决启动缓慢问题)
-Djava.security.egd=file:/dev/./urandom

深度解析：为什么要这么配？

• -Duser.timezone=Asia/Shanghai:

  • 痛点: 如果不加，JVM 会去读 /etc/localtime。在 Docker 容器中，由于基础镜像为了精简，往往没有安装 tzdata，导致 /etc/localtime 默认为 UTC。
  • 规范: 严禁使用 GMT+8（Java 某些版本解析会有微小偏差），严禁使用 CST（CST 同时代表中国标准时间、美国中部时间、古巴时间，极易混淆）。

• -Dsun.jnu.encoding=UTF-8:

  • 痛点: -Dfile.encoding 控制文件内容读写，而 -Dsun.jnu.encoding 控制文件名的解析。如果 Linux 文件名包含中文，且此参数未设，File.exists() 可能会莫名返回 false。

• -Djava.security.egd=file:/dev/./urandom:

  • 痛点: Tomcat 或 Spring Boot 启动时需要生成 Session ID 随机数。Linux 默认的 /dev/random 是阻塞的，当服务器熵池（Entropy）耗尽时，应用启动会卡住几分钟不动。改为非阻塞的 urandom 可秒级启动。

---

3.2 推荐的健壮性参数 (建议配置)

# 1. DNS 缓存策略 (微服务环境必配)
# 默认 JVM 可能永久缓存 DNS 解析，导致切量或容灾切换后 IP 不变
-Dsun.net.inetaddr.ttl=60

# 2. 临时目录指定 (防止 /tmp 清理导致异常)
-Djava.io.tmpdir=/data/java/tmp

---

3.3 故障现场保留参数 (保命配置)

当发生 OOM（内存溢出）时，如果没有 Dump 文件，神仙也难救。

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/dump/heap-error.hprof

---

4. 统一启动脚本模版 (Standard Launch Script)

建议将此脚本固化到 CI/CD 流程或 Docker Entrypoint 中。

#!/bin/bash
# -----------------------------------------------------------------------------
# Standard Java Boot Script - Ops Certified
# -----------------------------------------------------------------------------

# === 1. 项目配置区 ===
APP_NAME="xxl-job-admin"
JAR_FILE="${APP_NAME}.jar"
LOG_DIR="/data/logs/${APP_NAME}"
TMP_DIR="/data/tmp/${APP_NAME}"

mkdir -p ${LOG_DIR} ${TMP_DIR}

# === 2. 核心参数组 (不可修改) ===
# 所有的 -D 参数汇聚于此
CORE_OPTS=" -Duser.timezone=Asia/Shanghai \
            -Dfile.encoding=UTF-8 \
            -Dsun.jnu.encoding=UTF-8 \
            -Djava.awt.headless=true \
            -Djava.security.egd=file:/dev/./urandom \
            -Djava.io.tmpdir=${TMP_DIR} \
            -Dsun.net.inetaddr.ttl=60 "

# === 3. 内存与GC策略 (根据机器规格调整) ===
# 示例：4G 内存机器
MEM_OPTS=" -Xms2g -Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m "

# === 4. 故障排查 ===
DEBUG_OPTS=" -XX:+HeapDumpOnOutOfMemoryError \
             -XX:HeapDumpPath=${LOG_DIR}/oom.hprof "

# === 5. 最终执行 ===
#  关键顺序: java [JVM参数] -jar [应用] [业务参数]
echo "Starting ${APP_NAME} with standardized opts..."

nohup java ${CORE_OPTS} ${MEM_OPTS} ${DEBUG_OPTS} \
    -jar ${JAR_FILE} \
    --server.port=8080 \
    > ${LOG_DIR}/catalina.out 2>&1 &

---

5. 常见错误排查 (Red Flags)

作为 Tech Lead，在 Code Review 或上线检查时，看到以下情况直接打回：

1. 错误顺序: java -jar app.jar -Duser.timezone=Asia/Shanghai

   • 后果: -D 参数放在 jar 包后面，会被识别为 main(args) 的参数，JVM 本身根本不会读取，时区设置完全失效。

2. 使用 System.setProperty: 在 Java 代码里写 System.setProperty("user.timezone", "Asia/Shanghai")。

   • 后果: 太晚了！很多静态变量（static fields）在类加载时就已经初始化完毕，代码里再改时区可能对部分组件（如 Logger 初始化）无效。必须在 JVM 启动层面指定。

3. 依赖 OS: "我服务器已经设置好时间了，为什么还要加参数？"

   • 反驳: 运维准则第一条——环境是不可信的。不管是迁云、容器化还是灾备，显式配置能保证应用在任何基础设施上表现一致。

6. 数据库连接层配套规范

除了 JVM，JDBC 连接字符串也必须强制指定时区，形成双重保障：

MySQL/MariaDB URL 规范:

Properties

# 必须带上 serverTimezone=Asia/Shanghai
jdbc:mysql://db-server:3306/mydb?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai