如何优化CentOS Tomcat的启动速度

CentOS 上 Tomcat 启动慢的优化步骤

一 先定位瓶颈

• 查看 catalina.out 与 localhost-startStop-1 日志，若出现如下字样，多半是 SecureRandom 初始化慢：“Creation of SecureRandom instance for session ID generation … took [55,507] milliseconds.”
• 检查系统熵值：执行 cat /proc/sys/kernel/random/entropy_avail，数值很低（如个位数或几十）时，/dev/random 会阻塞，导致启动卡住。以上现象与低熵高度相关，应优先处理熵源问题。

二 快速修复 提升熵源

• 方案 A（系统级，推荐）：安装并启用硬件随机数服务，持续为熵池“喂料”
  • 安装：yum install -y rng-tools
  • 启动：systemctl start rngd && systemctl enable rngd
  • 如 CPU 支持 RDRAND，可先确认：grep rdrand /proc/cpuinfo该方式从根本上提升熵池可用性，对安全与性能兼顾。
• 方案 B（JVM 侧，见效最快）：让 JVM 使用非阻塞熵源
  • 修改 $JAVA_HOME/jre/lib/security/java.security：将 securerandom.source=file:/dev/random 改为 securerandom.source=file:/dev/urandom
  • 或在 $CATALINA_HOME/bin/setenv.sh 中添加（推荐做法，避免改动全局 JDK 配置）：export JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/urandom"二者取其一即可，通常能立即缩短启动时间。

三 JVM 启动参数优化

• 在 $CATALINA_HOME/bin/setenv.sh 中统一配置（文件不存在则新建，赋予可执行权限）：
  • 示例（按应用内存与延迟目标调整）：

    export JAVA_OPTS="-server -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=500 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/ -Djava.security.egd=file:/dev/urandom"

  • 说明：
    • 将 -Xms 与 -Xmx 设为相同值，减少运行期扩缩堆带来的停顿；
    • 大堆或低延迟诉求优先 G1GC；
    • 生产环境建议开启 HeapDumpOnOutOfMemoryError 便于排障。通过合理的堆与 GC 策略，可降低初始化阶段的 GC 抖动，提升整体启动与稳态表现。

四 Tomcat 配置与服务优化

• 连接器与线程模型（server.xml）：
  • 使用 NIO 或 APR 提升 I/O 能力（APR 需安装 native 库）；
  • 合理设置线程与超时，示例：

    <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200" minSpareThreads="50" acceptCount="100" connectionTimeout="20000" enableLookups="false" compression="on" compressionMinSize="2048" compressibleMimeType="text/html,text/xml,text/plain,application/json" />

• 应用部署策略：
  • 非必要可关闭自动部署与热部署，减少启动期扫描与部署开销：

    <Host name="localhost" appBase="webapps"unpackWARs="true" autoDeploy="false" deployOnStartup="false" />

• 文件描述符与内核参数（按需）：
  • limits.conf 提升进程可打开文件数：* soft nofile 65536、* hard nofile 65536；
  • sysctl.conf 优化网络与文件句柄：fs.file-max=65536、net.core.somaxconn=65535、net.ipv4.tcp_tw_reuse=1；
  • 如存在透明大页导致抖动，可禁用：echo never > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defrag以上能减少连接排队、提升并发与启动期的资源就绪速度。

五 验证与回退

• 验证步骤：
  • 重启后在日志中确认不再出现 SecureRandom 长时间初始化；
  • 执行 cat /proc/sys/kernel/random/entropy_avail 观察熵值是否充足；
  • 使用 systemd-analyze blame（若以 systemd 管理）或脚本化多次启动取平均耗时，量化优化收益。
• 回退建议：
  • 若修改了 java.security，建议备份原文件；
  • 如启用 APR 导致启动异常，可切回 NIO 并移除 native 依赖验证。
• 风险提示：
  • 将 securerandom.source 改为 /dev/urandom 在极少数高安全场景可能略降随机强度，优先采用“启用 rngd”的系统级方案；
  • 任何参数变更先在测试环境验证，再推广至生产。