第3章 系统环境与配置准备：硬件配置、操作系统参数、中间件版本对启动的影响
这一章我们聊聊环境。说白了，WMS 启动慢，很多时候不是代码的问题，而是你跑在什么机器上、操作系统怎么调的、中间件版本是不是有坑。
我遇到过不少团队，一上来就盯着业务代码优化，吭哧吭哧改了半天，启动时间也就降了几秒。后来我让他们看看机器配置，结果好家伙——磁盘还是机械盘，文件句柄限制1024，Tomcat 还是 7 的老版本。全部调完之后，启动时间直接砍半。
所以呢，在开始分析启动耗时之前，先把你手里的环境摸清楚。下面这三块，缺一不可。
启动耗时 = 硬件底子 × 操作系统调优 × 中间件版本
任何一个短板，都会成为启动瓶颈。
3.1 硬件配置——别让物理瓶颈拖后腿
启动时系统要加载大量类、解析配置、建立连接。这些活儿大部分落在 CPU 和磁盘上。我个人的习惯是，拿到新环境第一件事就是看 lscpu、free -h、iostat -x 1 10 这三个命令的输出。
快速自检清单：
- CPU 主频 ≥ 2.5GHz，核数 ≥ 4（虚拟机环境尤其小心超分）
- 内存至少预留 4GB 给 JVM，总内存 ≥ 8GB
- 磁盘必须是 SSD，IOPS ≥ 5000（机械盘启动时间可能翻 3 倍以上）
- 网络延迟 < 1ms（跨机房启动时数据库连接会卡很久）
我记得有个项目，WMS 启动一直卡在“初始化数据库连接池”阶段，等了将近两分钟。一查，数据库服务器是机械盘，MySQL 本身启动就慢，再加上网络延迟 3ms，连接池验证超时重试了好几次。后来换了 SSD，连接池初始化从 120 秒降到 8 秒。
注意： 云主机普遍存在 CPU 超分问题。你买的是 8 核，但宿主机可能跑了几十个虚拟机。启动时竞争激烈，耗时可能翻倍。建议用 stress --cpu 4 模拟负载后观察启动时间。
3.2 操作系统参数——那些容易被忽略的内核调优
硬件没问题，启动还是慢？那你想想看，操作系统默认参数是为通用场景设计的，WMS 这种企业级应用一启动就要开几百个线程、读取上万个文件，默认的 ulimit 很可能不够用。
3.2.1 文件句柄限制
很多 WMS 使用 Tomcat + Spring Boot，启动时加载 JAR 包、读取配置文件、打开日志文件，句柄数轻松上千。默认 ulimit -n 1024 很快就会被耗尽，这时候线程会阻塞在打开文件上。
# 查看当前限制
ulimit -n
# 临时调大
ulimit -n 65535
# 永久生效（/etc/security/limits.conf）
* soft nofile 65535
* hard nofile 65535
我曾经遇到一个案例，WMS 启动报错 Too many open files，排查了半天，结果就是句柄限制太小。调完之后，启动时间从 45 秒降到 32 秒。
3.2.2 内核参数（sysctl）
几个关键参数：
| 参数 | 推荐值 | 作用 |
|---|---|---|
net.core.somaxconn | 1024 | 提高 TCP 连接队列大小，避免连接池建立时丢包 |
vm.swappiness | 1 或 10 | 减少 Swap 使用，避免 JVM 因内存换页而卡顿 |
fs.file-max | 2097152 | 系统级文件句柄上限 |
kernel.pid_max | 65536 | 防止线程数上限不够（WMS 线程池经常几百个） |
你可能会问：为什么 Swap 会影响启动？说白了，JVM 在启动阶段要大量分配堆内存，如果系统内存紧张，部分页面被换到磁盘，那么 GC 和类加载都会变慢。我一般直接关掉 Swap，或者设置 swappiness=1。
3.2.3 NUMA 配置
在多路服务器上，NUMA 节点间内存访问延迟差距很大。如果 JVM 被分配到跨 NUMA 节点运行，启动时类加载和数据初始化会变慢。我建议在启动脚本中加上 numactl --interleave=all 或者绑定到单个节点。
# 绑定到 NUMA 节点 0
numactl --cpunodebind=0 --membind=0 java -jar wms-service.jar
一个小经验： 很多 Linux 发行版默认开启了透明大页（Transparent Hugepages），对于 WMS 这种长时间运行的应用来说，它会导致内存碎片和偶发卡顿。我通常会关掉它：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag启动时间能稳定缩短 5% 左右。
3.3 中间件版本——版本差异带来的启动时间波动
同一个 WMS 部署包，换一个中间件版本，启动时间可能差出十几秒。我遇到过几次线上问题，就是因为升级了 Spring Boot 版本，结果类自动配置扫描变慢。
3.3.1 应用服务器版本
Tomcat 8.5 到 9.0 启动时类的扫描方式有优化。Undertow 作为嵌入式容器，启动速度通常比 Tomcat 快 15-20%。如果你用的是 Spring Boot，强烈推荐换成 Undertow：
// pom.xml 排除 Tomcat 引入 Undertow
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
我试过一个案例，替换后 WMS 启动从 28 秒降到 22 秒，效果很明显。
3.3.2 数据库版本与驱动
MySQL 5.7 到 8.0 改进了连接握手机制，但如果你驱动版本没跟上，连接池初始化时还是走老协议，会多几次往返。建议使用 mysql-connector-java 8.0.x 配合 useSSL=false&allowPublicKeyRetrieval=true 参数。
3.3.3 JDK 版本
这点很多人会忽略。JDK 8 到 JDK 11，类加载机制有变化，JIT 编译启动更快。我个人的基准测试：同样的 WMS 应用，JDK 11 比 JDK 8 启动快 10-18%。如果是 JDK 17，受益于封闭类的优化，还能再快 5%。
避坑指南： 不要为了追求启动速度而使用最新的大版本，比如直接上 JDK 21，万一有兼容性问题反而更麻烦。我一般选择 LTS 版本（JDK 11 或 JDK 17），并配合对应的 GC 策略（G1GC 减少启动时 Full GC 停顿）。
3.4 把环境准备好，再谈优化
总结一下，系统环境这块我一般分三步走：
- 硬件摸底 —— 用工具跑一遍，确认没有物理瓶颈。
- 操作系统调优 —— 改句柄、关大页、调内核，几句话搞定。
- 中间件版本检查 —— 确认应用服务器、数据库、JDK 都是当前主流的成熟版本。
做完这些，再去看启动日志里的耗时细节，你会发现很多“慢”的假象其实就消失了。
我的常用命令组（塞到 .bashrc 里，新机器上跑一下）：
#!/bin/bash
# 硬件检测
echo "=== CPU ===" && lscpu | grep -E "Model name|Core|Thread"
echo "=== Memory ===" && free -h
echo "=== Disk ===" && iostat -d -x 1 1 | grep -v "^$"
# OS参数检查
ulimit -n
sysctl vm.swappiness
cat /sys/kernel/mm/transparent_hugepage/enabled