Tomcat环境变量配置后CPU飙高，大概率是CATALINA_OPTS参数组合打破资源平衡所致：如-Xms/-Xmx设等值但物理内存不足引发页换入换出、-Xss过小导致线程反复创建崩溃、误加调试参数引发高频系统调用，或maxThreads与-Xss未联动调整致虚拟内存暴涨及上下文切换激增。
Tomcat环境变量配置后CPU飙高，大概率不是配置本身导致的，而是配置触发了底层资源分配失衡或线程行为异常——比如 CATALINA_OPTS 里堆内存设得过大但线程池没同步调整，或 -Xss 过小引发栈溢出重试，又或者误加了调试/监控参数持续采样。直接改回默认值并不能定位根因，得顺着「配置变更 → JVM行为变化 → 线程状态偏移 → CPU消耗模式改变」这条链路查。
为什么改了CATALINA_OPTS之后CPU突然上100%？
常见诱因不是参数写错，而是参数组合打破了原有平衡：
-
-Xms和-Xmx设为相同值（如-Xms4G -Xmx4G）本意是避免GC抖动，但如果物理内存不足或系统已启用Swap，JVM会频繁触发内存页换入换出，表现为CPU在内核态（sy%）飙升 -
-Xss256k在高并发场景下可能太小，导致线程创建失败后反复重试，或StackOverflowError被静默吞掉并重入逻辑，形成忙等循环 - 误加
-XX:+PrintGCDetails -Xloggc:...且日志路径不可写，JVM会不断尝试打开文件句柄，引发大量系统调用和锁竞争 - 混用
JAVA_OPTS和CATALINA_OPTS，造成重复设置（如-Dfile.encoding冲突），某些类加载器陷入死循环解析系统属性
如何快速确认是不是环境变量惹的祸？
别急着删配置，先做三件事验证因果关系：
- 用
jps -l查到 Tomcat 主进程 PID，再执行ps -o pid,ppid,cmd -p <pid></pid>，确认启动命令里实际生效的 JVM 参数——有时bin/catalina.sh里写错了位置，参数根本没进命令行 - 运行
jstat -gc <pid> 1000 3</pid>，观察YGC、FGC次数是否在 1 秒内激增；如果 GC 频率正常但top -Hp <pid></pid>显示多个线程 CPU 占用持续 >90%，问题大概率在线程逻辑而非 GC - 临时注释掉
CATALINA_OPTS中所有非内存类参数（比如去掉-XX:+UseG1GC、-Dcom.sun.management.jmxremote），只留-Xms/-Xmx，重启看 CPU 是否回落——能回落就说明是某个开关型参数激活了副作用
maxThreads 和 -Xss 必须联动调优
很多人单独调大 maxThreads 却忽略栈空间总消耗，结果线程数上去了，每个线程的 -Xss 又没压下来，总虚拟内存（VIRT）暴涨，触发 Linux OOM Killer 或引发大量 minor fault，CPU 就卡在页错误处理上：
- 假设
maxThreads=500，默认-Xss=1M，光线程栈就占 500MB 虚拟内存；若改用-Xss=256k，可省下 375MB，对容器化部署尤其关键 - 但
-Xss不是越小越好：Spring AOP、深层递归 JSON 序列化、复杂正则匹配都可能突破 256k，此时线程会抛StackOverflowError后立即重建，形成「创建→崩溃→重建」循环，top -Hp里能看到大量短命线程 PID 飙升 - 稳妥做法是先用
jstack <pid> | grep java.lang.Thread.State | wc -l</pid>统计当前活跃线程数，再按「活跃线程数 × 384k」反推安全的-Xss下限，而不是盲目设 128k
真正麻烦的是那些不报错但空转的线程——比如线程池里一堆 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject，看着 idle 实际在自旋检查条件，jstack 里找不到明显堆栈，得结合 vmstat 1 看 cs（context switch）是否异常高。这种时候，环境变量只是导火索，背后往往是业务代码里一个未关闭的定时任务或连接泄漏，配置放大了它的危害。不要只盯着 CATALINA_OPTS 改来改去，先抓线程快照比对变更前后的差异更有效。
