企业官网建设流程全解析

先说一个我印象特别深的场景。去年某天晚上七点多，我刚准备下班，监控群突然炸了：一个积分结算系统接口的P99从50毫秒直接飙到6秒，超时率冲上30%。第一反应是加机器，但扩容之后情况一点没好转，CPU使用率也只有20%出头，内存看着也不紧张。一群人围在屏幕前看GC日志、看线程栈，折腾了一个多小时才定位到根因——不是代码写得多烂，而是JVM参数和线程池配置被默认值坑了五年。

后来我复盘这类问题，发现大部分Java性能事故都有一个共同特点：系统不是被某个复杂算法拖垮的，而是被那些看起来“没啥问题”的基础配置、调用习惯和监控盲区一点点积累出来的。这篇文章不打算写成教科书式的“性能调优大全”，而是把我这些年实际遇到过的场景、踩过的坑、用过的排查手段，以及最后生效的优化动作，按条理整理成一份可以照着做的实战笔记。涉及内存、GC、线程池、数据库、缓存、工具链，也会给你一些能直接拿去用的参数和命令。

1. 先搞清楚目标：性能调优到底在调什么

1.1 那个CPU很低但系统很慢的夜晚

前面说的那个积分系统，最让人迷惑的地方就是CPU一点都不高，平均只有20%左右，但接口就是慢。很多人遇到这种情况第一反应是“线程数不够了”，于是把Tomcat线程池从200调到500，结果没有变好，反而更糟。原因不难理解：线程都堵在数据库连接或远程调用上，加线程只是让更多请求挤在同一个等待队列里，上下文切换开销反而上去了。

这个案例给我最大的教训是：性能调优第一步不是优化，而是定位。CPU低但响应慢，通常意味着线程处于等待状态——等数据库、等网络、等锁、等磁盘IO。此时CPU是闲着的，瓶颈在外部资源或者线程调度上，盯着CPU使用率看基本没有用。反过来，CPU跑满但吞吐上不去，那才是关注代码计算效率的时候。

1.2 响应时间与吞吐量：一对需要先权衡的指标

做性能优化之前，得先定义清楚“快”的标准。我习惯把指标分成两类：响应时间和吞吐量。

• 响应时间：通常看平均值、P95、P99。P99代表99%的请求都落在某个耗时以内，它比平均值更能暴露长尾问题。
• 吞吐量：单位时间内能处理的请求数，常见的就是QPS、TPS。

这两者并不总是一起变好。比如批量处理场景，为了把吞吐量拉起来，可能单次请求耗时反而会变长。处理这种矛盾，要先看业务SLA——用户能接受多慢的响应？系统要求每秒处理多少笔？然后再决定优先优化哪一头。

我用一个餐厅例子来理解：响应时间相当于“客人从点菜到上菜的时间”，吞吐量相当于“餐厅一晚上能接待多少桌客人”。如果只顾着提高翻台率，每桌吃太快，客人体验会变差；如果每桌都精雕细琢，翻台率就下来了。线上系统也一样，调优本质是寻找当前业务约束下的平衡点。

我建议每个服务上线前就建立一张指标记录表，至少涵盖这些维度：

有了这张表，再看“系统慢”才不会各说各话。

1.3 别把优化做成八股文背诵现场

现在网上Java面试题很多，关于HashMap原理、Synchronized锁升级、GC算法选择，大家都能说几句。但说句实在话，线上排查性能问题的时候，面试八股文能帮上的忙非常有限。

我见过一个团队给Spring Boot服务加了这样一组参数：

-XX:+UseG1GC -XX:MaxGCPauseMillis=10

他们的想法很简单：G1不是号称能控制停顿吗？那把最大停顿压到10毫秒，系统不就不卡了？结果上线后GC频率暴增，吞吐量反而跌了。原因在于MaxGCPauseMillis设得太小，G1会不断调整年轻代大小来满足停顿目标，同时回收线程要频繁扫描，最终大量CPU时间都花在GC上，业务线程反而跑不动了。

这种问题的根源就是只背了“结论”，没理解参数背后的权衡逻辑。遇到性能问题，正确的姿势是先看监控数据，再做假设，用工具验证，最后才动手改配置。没有数据支撑的优化，就是碰运气。

2. JVM内存与GC：最容易被参数误导的地方

2.1 从一次OutOfMemoryError事故说起

有一个定时结算任务，每天凌晨3点跑一次，平时都很安静。某天早上运维告诉我任务挂了，日志里有一行红字：java.lang.OutOfMemoryError: unable to create new native thread。

我看到这个错误的第一反应是“内存爆了”，但仔细想了下不对。unable to create new native thread翻译过来是不能创建新的操作系统线程，通常和堆内存大小没有直接关系，而是线程数达到系统上限，或者进程虚拟内存不足导致线程栈分配失败。

排查过程是这样的：

# 查看系统对单个进程的最大线程数限制 ulimit -u # 统计当前进程创建了多少线程 ps -eLf | grep <pid> | wc -l # 查看进程内线程数 cat /proc/<pid>/status | grep Threads

一查发现，这个任务的线程数已经接近系统上限。再看代码，原来是任务里使用了一个无界的线程池，每次处理一批数据就提交一个新的任务，线程只增不减。正常数据量下没问题，但那天数据量翻了几倍，积压的任务越堆越多，线程自然就失控了。

这里补充一个经验：Java的OOM按错误类型分好几种，排查路径完全不同。我整理了一个简单对照表：

包括热搜词里提到的java.lang.OutOfMemoryError: insufficient memory，虽然看起来也是“内存不够”，但很多情况下是容器限制或Linux物理内存不足，而不是Java堆不够用。判断依据很简单：先看JVM监控里堆内存水位，再看宿主机/容器的内存使用。堆内存还有余量，但进程被杀了，那多半是容器超限或者操作系统OOM Killer动手了。

2.2 G1参数为什么不能照抄别人的

网上关于G1调优的文章很多，但真正理解G1设计目标的没几个。G1的核心思路是在满足停顿时间约束的前提下，尽量提高吞吐量。它把堆分成多个Region，通过维护一个可预测的回收集合，来控制每次GC的停顿。

这里就有一个关键点：-XX:MaxGCPauseMillis这个参数不是“我希望GC停顿多久”，而是“G1会努力把GC停顿控制在这个范围内”。如果这个值设置得太小，比如10毫秒，G1就会为了让停顿达标，频繁触发年轻代回收，导致CPU大量消耗在GC上，应用吞吐量明显下降。

我一般给通用业务服务这样配置（以8GB堆内存为例）：

-Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1NewSizePercent=5 -XX:G1MaxNewSizePercent=60 -XX:G1HeapRegionSize=16m -XX:+ParallelRefProcEnabled

解释一下几个关键参数：

• -Xms和-Xmx设为一致，避免运行时动态扩容带来的抖动。这在容器化环境里尤其重要，因为动态扩缩容会导致性能不稳定。
• MaxGCPauseMillis=100是一个比较平衡的默认值，不要盲目追求降到几十毫秒。
• G1NewSizePercent和G1MaxNewSizePercent控制年轻代的最小和最大占比。适当调大年轻代可以减少Young GC频率，但会牺牲一部分老年代空间，要根据对象分配速率调整。
• G1HeapRegionSize一般不需要手改，默认会自动计算。如果大对象比例高，可以适当调大到16m或32m，减少大对象跨Region分配的开销。

调G1参数有个原则：先跑两天看数据，再动参数，一次只动一个。我见过太多人一口气改四五个参数，出问题后根本不知道是哪个引起的。

2.3 一次Full GC排查的完整还原

另一个典型的案例是单机服务每到下午某个时段就出现接口卡顿，时长大概持续二十分钟。我看了下监控，发现那个时段Old区占用率从40%一路涨到90%，然后触发Full GC，止损后回落，数据越好，出现周期性“锯齿”。

排查步骤我来还原一下：

第一步，用jstat看GC情况：

jstat -gcutil <pid> 1000

输出里能明显看到FGC（Full GC次数）在持续增加，每次Full GC耗时要好几秒，这已经是很危险的信号了。

第二步，用jmap或jcmd看堆里的对象分布：

jcmd <pid> GC.class_histogram | head -30

这里我特别强调一下，生产环境尽量用jcmd而不是jmap -histo:live，因为后者会触发一次Full GC，线上操作风险很高。我一般直接在测试环境复现，或者用Arthas的heapdump命令在低峰期执行。

结果出来后，排名靠前的居然是一个业务DTO对象和日志对象。反查代码发现，某段循环逻辑里每处理一条数据都打了一条info日志，日志框架的异步队列里堆积了大量待写入对象。数据量一大，队列不断膨胀，就成了老年代里的“钉子户”。

修复并不复杂：把关键日志从info降到debug，或者加一个采样开关，只打印前N条和异常数据。日志队列长度也做了限制，避免无界队列继续吞内存。改完之后，再观察那个时段的曲线，锯齿明显平缓了，Full GC基本消失。

这个案例给我的经验是：GC问题往往不是GC本身的问题，而是代码在不停地制造垃圾。调GC参数只能缓解症状，真正解决问题要找到谁在疯狂创建对象。把这个问题想明白，性能调优就算入门了。

3. 线程与并发：高并发不是“多开几个线程”这么简单

3.1 线程池参数不是拍脑袋定的

很多刚接触并发的同学喜欢直接用Executors提供的快捷方法，比如Executors.newFixedThreadPool(50)。这个写法在低并发、低流量的时候看不出问题，但一旦业务量上来，就会成为定时炸弹。

我说一个真实的批量导出场景。系统里有一个导出任务，内部用newFixedThreadPool(50)并发处理数据，队列是默认的无界LinkedBlockingQueue。某个大促日，数据量突增，50个线程全部阻塞在数据库查询上，新任务不断提交，全部堆积在无界队列里。结果内存上涨，服务假死，接口大面积超时。

问题根源有两个：无界队列导致任务无限堆积；线程数固定，但线程都在等IO，没在真正干活。

Java并发编程里，线程池的核心参数是这几个：

• corePoolSize：常驻线程数
• maximumPoolSize：最大线程数
• workQueue：等待队列
• handler：拒绝策略

它们的关系是：任务提交时，先尝试交给核心线程；核心线程满了，放到队列；队列满了，才创建新线程直到maximumPoolSize；再满，就执行拒绝策略。很多人误以为maximumPoolSize是“只要线程不够就扩展”，其实只要队列没满，线程数就不会往maximumPoolSize走。

线程数的经验估算，我一般分两种场景：

• CPU密集型：线程数大约等于CPU核数+1，避免过多线程导致上下文切换。
• IO密集型：线程数可以远大于核数，因为线程大量时间在等待IO。一个常用公式是：线程数 = CPU核数 × (1 + 等待时间/计算时间)，但这个等待时间需要压测采样，实际项目中可以先用CPU核数 × 2起步，再逐步调整。

我建议所有线上服务都手动创建ThreadPoolExecutor，明确四个核心参数和队列长度，不要用Executors的快捷方法。拒绝策略上，如果是重要任务，CallerRunsPolicy是一个稳妥选择——不会丢任务，只是让提交线程自己跑，起到天然限流的作用。

3.2 从jstack转储看一次“假死”

有一次线上服务进程还活着，但所有请求都在超时，健康检查也快挂了。这时候第一件事就是抓线程转储：

jstack -l <pid> > /tmp/thread_dump.txt

打开转储文件，能看到大量线程处于WAITING (parking)状态，但继续往下刷，发现有一组线程卡在BLOCKED状态，等待同一把锁。

在jstack输出里，waiting to lock <0x00000000xxxx> (a java.util.HashMap)这种信息就是关键线索。定位到锁之后，再结合业务代码找持有锁的线程——谁持有了这把锁，并且长时间不释放，基本就是元凶。

那次问题的根因是代码里用了Collections.synchronizedMap来缓存数据，某个高峰期频繁读写，持锁线程又调了一个远程接口，导致锁被占住十几秒。后面一堆请求全堵在锁上，CPU不高，但系统就是不响应。

如果用Arthas，排查会更方便：

thread -n 3

这条命令直接列出CPU占用最高的几个线程并打印堆栈。也可以用thread --state BLOCKED看有多少线程处于阻塞状态，比手动翻jstack快很多。

这类问题教给我一个判断方法：CPU高，优先看火焰图和线程执行热点；CPU低，优先找阻塞和等待。两个方向不对应，死活都定位不到问题。

3.3 类加载问题为什么总在运行时才暴露

说个跟热搜词有关的细节：java.lang.NoClassDefFoundError: java/applet/applet。这不是一个高频问题，可一旦出现，很多人会懵——因为代码里根本没有引用过Applet相关的类。

我遇到过类似场景：一个老项目从JDK 8升级到JDK 11，启动时一切正常，但运行到某个功能时突然报错。原因就是旧代码或某个第三方依赖，在运行时通过反射或间接方式引用了java.applet.Applet——这个API在JDK 9之后已经被模块化移除。

ClassNotFoundException和NoClassDefFoundError的区别要分清：

• ClassNotFoundException通常是在代码里显式用Class.forName加载类时找不到，属于“主动发现”。
• NoClassDefFoundError通常是类在编译期存在，运行期第一次加载时失败，属于“被动暴露”。可能是类初始化失败，也可能是依赖的类缺失。

排查方法很简单，用JVM参数打印类加载过程：

java -XX:+TraceClassLoading -jar app.jar

或者用Arthas的sc命令查询某个类是否已经被加载：

sc java.applet.Applet

这种问题比内存问题隐蔽得多，因为它在编译期根本不会报错。升级JDK版本时一定要做依赖扫描，重点检查已经移除或不再推荐的API。搜索引擎里能搜到大量这类报错，本质上都是同样的原因。

4. 数据库与缓存：瓶颈往往不在Java层

4.1 索引失效：成本最低的优化

性能调优有一类“便宜”的优化，不需要改架构，不需要加机器，改一行SQL就能快上几十倍——那就是索引优化。我见过一个查询，表数据量500万，语句长这样：

SELECT * FROM trade_log WHERE DATE(create_time) = '2025-01-01';

这条SQL跑了2秒，加索引也没用，因为在索引列上用了DATE()函数，导致索引失效，全表扫描。

改成范围查询之后：

SELECT * FROM trade_log WHERE create_time >= '2025-01-01 00:00:00' AND create_time < '2025-01-02 00:00:00';

同样条件下，查询耗时降到50毫秒以内。这种优化收益巨大，几乎零成本，关键是“查问题”的思路要对。

我总结了几个最常见的索引失效情况：

• 在索引列上使用函数或表达式，比如WHERE DATE(create_time) = ...。
• 隐式类型转换，比如字符串列用了数字去匹配，导致索引失效甚至结果集错乱。
• 前导模糊查询，比如LIKE '%keyword'，索引无法命中。
• 联合索引不满足最左前缀原则。

遇到慢SQL，第一步永远是EXPLAIN看执行计划，重点看type、key、rows、Extra。type是ALL意味着全表扫描，key是NULL说明索引没用到，Extra里出现Using filesort要关注排序性能。

4.2 RedisTemplate.increment()报错引发的思考

有一个具体报错一直挺经典：用RedisTemplate.opsForValue().increment("counter")时，Redis返回ERR value is not an integer or out of range。看到这个错误，很多人第一反应是“Redis坏了”或者“并发写进去脏数据”，其实都不是。

排查过程是这样的：先用redis-cli进到对应的Redis实例，看这个key的类型和值：

type counter get counter

结果type返回的是string，但get出来一串类似\xAC\xED\x00\x05t\x00...的乱码。看到这个前缀，基本可以确定这个key是用了JDK序列化器写入的——也就是JdkSerializationRedisSerializer默认序列化的结果。

根因通常是应用里同时存在StringRedisTemplate和RedisTemplate两个Bean。前者默认用String序列化，后者默认用JDK序列化。如果两个组件往同一个key上写值，Redis里存的内容格式就会不一致，执行INCRBY时Redis要求value必须是数字字符串，碰到二进制序列化的内容自然就报错了。

解决方案很简单：

1. 统一序列化器。项目中如果有多个RedisTemplate，统一设置成StringRedisSerializer或JSON序列化。
2. 计数器场景强制使用StringRedisTemplate。它写入的值是纯字符串，不会出现序列化前缀。
3. 如果这个key已经脏了，先在低峰期删除重建，再继续累加。

这个案例还带出一个更广泛的判断：缓存出问题，先看数据长什么样，再看代码怎么写的。很多时候不是Redis性能不行，是客户端用法不规范。

4.3 连接池与本地缓存，别让Redis背锅

有一次服务压测，QPS到1000左右就开始报连接池超时。很多人第一反应是“Redis不够快”，其实是因为应用里每个请求都去读同一个热点key，连接池被打满了。

Redis连接池的参数和线程池一样，不是越大越好。HikariCP官网给过一个粗略估算思路：连接池大小主要看“单条查询延迟”和“QPS”的乘积。举个例子：

假设接口QPS=500，单次查询平均耗时=2ms 可估算连接数 = 500 × 0.002 = 1

算出来只有1个连接就够用，这当然极端了，但逻辑是对的：如果单次查询足够快，少量连接就可以支撑很高的QPS。反而把连接池配到200、300，数据库连接资源被大量占用，其他服务也跟着遭殃。

我另一个常用优化是本地缓存。热点数据如果允许秒级延迟，可以加一层Caffeine本地缓存，TTL设5秒到30秒。本地内存读取是纳秒级，Redis读取是毫秒级，两者差了三个数量级。加一层本地缓存之后，Redis的QPS能降一个数量级，接口延迟也更稳定。

但本地缓存不是银弹，它有一个一致性问题：数据更新时，各个实例的本地缓存可能短暂不一致。所以只适合“容忍秒级延迟”的业务场景，比如配置项、字典表、热门商品信息。要强一致性的数据，还是走Redis或者直查数据库更稳妥。

5. 工具链与复盘：把“感觉”变成“数据”

5.1 一次定位问题的工具组合拳

Java性能排查的工具链我一直放在手边，遇到问题基本按这个顺序出牌。

第一步，确认进程：

jps -l

第二步，看GC表现：

jstat -gcutil <pid> 1000

第三步，看线程状态：

jstack -l <pid> > /tmp/thread_dump.txt

第四步，需要看堆对象分布时：

jcmd <pid> GC.class_histogram | head -30

如果是线上环境，我会优先用Arthas。它有几个命令特别好用：

# 查看方法调用耗时，定位慢方法 trace com.example.OrderService createOrder # 实时查看方法返回值 watch com.example.OrderService createOrder returnObj # 查看当前热点线程 thread -n 3

trace命令能打印方法链路里每一步的耗时，特别适合排查“接口慢但不知道慢在哪”。watch可以不打断线上请求就能看到入参和返回值，排查诡异数据非常好用。

如果CPU飙到打满，就用async-profiler抓火焰图。火焰图能一秒看出CPU时间花在哪个方法上，比一行行看日志直观得多。

给一个从报警到定位的快速路径参考：

• CPU高 → 抓火焰图，找热点方法。
• CPU低但响应慢 → 看线程转储，找BLOCKED/WAITING线程；同时看数据库慢查询和Redis慢命令。
• 内存持续上涨 → 看GC曲线，抓堆转储，再用MAT或VisualVM分析对象占用。
• 接口间歇性卡顿 → 优先怀疑GC停顿或锁竞争，配合监控时间点交叉验证。

5.2 用JMH给可疑方法做体检

团队里经常会发生“这个写法性能更好”之类的争论，谁都说服不了谁。我的处理方式是不争论，用基准测试说话。JMH是JDK官方出品的微基准测试框架，专门用来测单个方法的性能。

举个例子，有人觉得String.format慢，有人说用字符串拼接就行，还有人说StringBuilder最快。写一个最简基准：

import org.openjdk.jmh.annotations.*; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.Throughput) @Warmup(iterations = 3, time = 1) @Measurement(iterations = 5, time = 2) @Fork(1) @Threads(4) public class StringBenchmark { private static final String NAME = "user"; private static final int ID = 12345; @Benchmark public String format() { return String.format("user:%s:%d", NAME, ID); } @Benchmark public String concat() { return "user:" + NAME + ":" + ID; } @Benchmark public String builder() { return new StringBuilder() .append("user:").append(NAME) .append(':').append(ID) .toString(); } }

跑完之后看吞吐量和平均耗时，数据一目了然。这类微基准测试要控制变量，别把IO操作放进去，否则结果会被外部因素干扰。

用JMH这件事本身也说明一个工作习惯：优化之前先度量，优化之后复测。没有前后对比的优化，很难评估到底有没有效果。

5.3 优化前后的量化对比与日常守护

做完整轮优化后，最好把结果用一张表记录下来，既是给团队的交代，也是给自己积累经验。我这里拿之前那个积分系统举例，同一套压测场景下，优化前后的数据大概是这样的：

看到CPU从20%涨到45%不要慌，这说明系统真正在干活了。之前线程都在空等，资源利用率低，吞吐也上不去。优化后CPU被更有效地利用，整体吞吐反而翻了好几倍。

关于日常守护，我自己有几个固定动作。每个月会挑一个低峰时段做一次压测，保留历史压测报告做对比；每次发布前重点检查数据库查询、缓存操作、线程池参数有没有变化；监控告警阈值按P99设置，而不是平均值，否则长尾问题很容易被平均数据掩盖。这些动作不需要花太多时间，但能避免性能问题在发布后才集中爆发。

最后分享一个小习惯

每到大促前，我都会把三件事重新做一遍：压测脚本重新跑一遍，监控告警阈值重新确认，把所有定时批量任务在测试环境预演一遍。性能调优不是阶段性工作，更像是一种持续习惯——出了问题不急着改代码，先看数据；看到数据不急着下结论，先定位；定到位再去想最优解。这套流程帮我在很多项目里绕开了大坑，也希望这篇笔记能给你一些可对照、可复用的参考。