CentOS Java配置怎样优化

CentOS 上 Ja va 配置的优化路径

先说几个核心判断：在 CentOS 上跑 Ja va 应用，如果只是装好就开跑，那基本是在浪费硬件。真正的优化，是从系统底层到 JVM 参数再到中间件配置，一条线拉通来看的。下面把关键环节拆开揉碎了讲清楚。

一 基础环境与版本选择

JDK 版本这事儿其实没什么好纠结的。JDK 17 作为 LTS 版本，在性能、安全补丁以及虚拟线程这些新特性上都站得稳，多数场景下直接选它就行。如果是新项目，别再去碰 JDK 8 以下的版本了，能省不少事。

安装方式上，用包管理器装 OpenJDK 是最省心的：sudo yum install -y ja va-17-openjdk-devel。如果因为某些原因必须上 Oracle JDK，记得把许可问题先理清楚。环境变量建议写到全局配置里，比如 /etc/profile 或者 /etc/profile.d/ja va.sh，内容就这几行：

export JA VA_HOME=/usr/lib/jvm/ja va-17-openjdk
export PATH=$JA VA_HOME/bin:$PATH

装完了可以用 ja va -version 和 ja vac -version 快速验证一下。这一步虽然简单，但很多人偏偏在这里栽跟头——路径配错了还排查半天，挺冤的。

二 系统层面的优化

系统级别的优化，往往比 JVM 参数调优更立竿见影。首当其冲是内存换页问题。默认情况下 Linux 的 vm.swappiness 是 60，这意味着系统会相对积极地使用 Swap，这对 Ja va 应用来说简直就是抖动放大器。建议直接降到 10，必要时甚至可以更低。在 /etc/sysctl.conf 里设置，然后 sysctl -p 让它生效。

文件系统方面，XFS 或 ext4 都行，但挂载时记得加上 noatime 参数，能减少大量不必要的元数据写入。日志和数据目录最好放在独立的磁盘或分区上，免得日志写爆了把数据盘也拖死。

如果你的服务是短连接或者高并发场景，网络参数也需要动一动。下面这几个值是比较常用的起点：

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 1024
net.ipv4.ip_local_port_range = 1024 65535

配置完一样要 sysctl -p。除此之外，顺手把系统上不需要的服务和自启项关掉，别让它们跟你的 Ja va 进程抢 CPU 和内存。

三 JVM 内存与 GC 调优

堆大小这块，经验法则是把 -Xms 和 -Xmx 设为相同值。运行期让 JVM 自己去扩缩堆，带来的停顿往往得不偿失。具体设多大，得结合容器或物理机的内存总量以及业务峰值来定。线程栈 -Xss 默认值通常偏大，适当调小一点可以增加可创建的线程数，但别砍太狠，否则会栈溢出。

年轻代的大小用 -Xmn 或 -XX:NewRatio 来控制。一个常见的做法是让年轻代约占堆的 1/3 左右，当然这只是一个经验起点，最终需要压测来验证。

垃圾回收器的选择其实已经没什么悬念了：如果追求低停顿和可预测的停顿，G1GC 是目前最稳妥的选择。大堆且对吞吐量要求极高的批处理场景，Parallel GC 仍然有一席之地。CMS 在 JDK 14 就已经被移除了，新应用就别再纠结了。

另外几个容易忽略的点：如果你的应用用了 NIO 或 Netty，直接内存 OOM 是常见坑，记得设置 -XX:MaxDirectMemorySize。元空间方面，JDK 8 以后用的是 Metaspace，可以根据需要设一下 -XX:MaxMetaspaceSize，防止元空间无限制膨胀。

给一个 16GB 内存的通用服务场景参考配置（注意这只是起点，一定要压测微调）：

-Xms12g -Xmx12g -Xss512k
-XX:+UseG1GC -XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/app/logs/heap.hprof
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/app/logs/gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=100M

四 容器与中间件场景要点

这类场景下，中间件的配置与容器环境的适配才是真正的战场。拿 Tomcat 来说，连接器选 NIO 或 NIO2，maxThreads 设个 500 左右，acceptCount 设 100，maxKeepAliveRequests 设 100。不需要 AJP 的话直接关掉。内存参数通过 CATALINA_OPTS 传进去。

Spring Boot 则相对简单，在 systemd 服务文件或者启动脚本里把 JA VA_OPTS 或 JA VA_TOOL_OPTIONS 设置好就能生效，注意容器内外要保持一致。

容器化部署是个坑很多的地方。Docker 或 K8s 里一定要显式设置容器的内存上限，并且 JVM 的 -Xmx 绝不能超过这个 limit。否则一旦 JVM 的内存占用突破容器的限制，直接被 OOMKilled，连 GC 的机会都不给。

五 监控 诊断与持续优化

优化不是一次性的，它是个闭环。GC 日志必须开，而且得带上时间戳和日志轮转。发生 OOM 时自动生成 Heap Dump 这个选项也建议加上，否则等出了问题再想要 dump，就没机会了。

诊断工具方面，jstat、jstack、jmap 是基础的三件套。VisualVM、JProfiler、MAT 这些图形化工具适合做深度分析。系统层面，top、vmstat、iostat、netstat 轮流用，CPU、内存、磁盘 I/O、网络队列和重传这些指标都得盯住，联合起来定位瓶颈。

最后，调优一定要有明确的目标。比如：平均停顿控制在 1 秒以内，Full GC 间隔至少 24 小时，老年代使用率常态不超过 70%。先采集基线数据，然后每次只改一个变量，压测完对比效果，最后再上生产灰度。这才是专业调优的节奏，而不是凭感觉改几个参数就以为完事了。