线程同步与页面置换：从原理到实战的并发与内存调优指南

刚处理完一个线上服务的并发问题：多个线程同时向一个缓存结构里写数据，明明在代码里加了锁，线上还是偶发数据错乱。排查到最后，问题出在锁的实现方式上——一台高配机器上大量线程并发热切一个锁，互斥锁切换上下文耗掉了大半 CPU 时间片。换成读写锁加无锁读路径之后，问题立刻消失。

另一件事也很有意思。压测的时候内存被撑爆，服务频繁触发回收，吞吐直接腰斩。后来翻数据库和缓存的淘汰策略配置，发现用的还是最朴素的 FIFO 思路，完全没考虑热点数据，大量高频访问的数据被当成冷数据清了出去。换掉淘汰策略之后，命中率从 68% 拉到 91%，内存也没再报警。

这两个问题背后，一个是线程同步方式，一个是页面置换算法。前者解决多线程之间怎么安全高效地协作，后者解决内存不够时该怎么淘汰数据才划算。很多开发者对这两块知识的印象还停留在面试题上，但真正到生产环境里调优、排查问题才发现，每一个选择题背后都是一套取舍逻辑。这篇文章就把这两块内容串起来，从原理讲到实战选型，把关键参数和踩坑经验一并说清楚，适合正在做并发编程、服务端开发或者准备应对系统设计面试的读者。

1. 内容整体设计与思路拆解

把线程同步和页面置换放一起讲，不是因为它们都出现在操作系统课本里，而是因为它们本质上在解决同一个问题：资源有限，怎么协调并发访问才不出错、不浪费。

线程同步解决的是多线程争用共享资源时的有序访问问题。多个线程同时访问同一个变量、同一块缓存、同一个连接池，如果不加控制，就会出现竞态条件、数据不一致、死锁等问题。同步方式的选择直接影响程序的并发性能和可伸缩性。

页面置换解决的是内存不够用时，该把哪些页面换出、哪些页面保留的问题。操作系统或者缓存系统发现内存或存储空间不足，需要淘汰一些旧数据来腾位置，如果淘汰策略不行，就会频繁换入换出，系统性能断崖式下跌。

看到一个关键关联没有：**同步手段做得越糙，锁等待越久，线程切换越频繁，内存访问压力也会越大。而页面置换策略做得越差，缺页中断越多，磁盘 IO 越频繁，程序运行越慢，线程等待锁的时间也会进一步拉长。**这两个问题在生产环境里经常一起出现，放在一起讲，能帮大家建立起一个完整的性能调优视角。

本文的技术路线是这样的：

• 先逐层拆解线程同步的几种主流实现方式，讲清楚各自原理、适用场景和性能特征。
• 再深入页面置换算法的原理，对比常见算法的命中和代价。
• 最后把两者放到真实场景里，给出选型思路和排查技巧。

2. 线程同步核心机制解析

2.1 互斥锁：最基本的线程同步方式

互斥锁是线程同步里最基础的一种方式。它的核心思想是：同一时刻只允许一个线程进入临界区，其他线程必须等待。这个机制保证了对共享资源的访问是串行的，不会出现两个线程同时改写同一个数据的问题。

在具体实现上，互斥锁通常依托操作系统或硬件提供的原子操作。比如 x86 架构的xchg、lock cmpxchg指令，ARM 架构的ldrex/strex指令。开发者不需要直接写这些指令，语言层面的锁 API 已经封装好了底层细节。但从原理上理解，锁的获取过程就是“尝试修改一个标志位，如果修改成功则获得锁，否则等待”。

#include <pthread.h> pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; int shared_counter = 0; void *worker(void *arg) { for (int i = 0; i < 100000; i++) { pthread_mutex_lock(&lock); shared_counter++; pthread_mutex_unlock(&lock); } return NULL; }

上面这段代码是教科书式的互斥锁使用方式。每次自增操作都加锁，逻辑上完全正确，但性能上确实有大问题——锁的获取和释放都是有成本的。一次锁操作涉及用户态到内核态的切换、等待队列的管理、线程调度，如果这个操作在循环里执行十万次甚至百万次，开销就会被放大得非常夸张。

实际测试数据是：在一台 2.6GHz 的服务器上，简单的pthread_mutex加锁解锁一次的耗时大约在 20-50 纳秒，但如果发生锁竞争导致线程被挂起再唤醒，一次切换的耗时可能会到微秒甚至几十微秒级别。一个高频访问的临界区如果锁竞争严重，性能会差出两三个数量级。

提示：互斥锁适合临界区执行时间较长、竞争不那么激烈的场景。如果临界区非常短（只做几次加法、一次指针赋值），那么锁本身的成本可能比临界区操作的成本还高，这时候要考虑更轻量的方案。

2.2 自旋锁：短临界区的第一选择

自旋锁和互斥锁最大的区别在于：互斥锁拿不到锁的时候会把线程挂起，让出 CPU；自旋锁拿不到锁的时候会在原地忙等，反复检查锁状态，直到拿到锁为止。这里的核心差异就是“阻塞还是忙等”。

自旋锁的优势是避免了线程切换的开销。线程切换涉及保存恢复寄存器、更新调度队列、可能会触发 cache miss 和 TLB shootdown，这个成本远远高于在 CPU 上原地转几圈的能耗。所以当临界区很小、锁持有时间极短时，自旋锁的效率远高于互斥锁。

但自旋锁的劣势也很明显：忙等会持续消耗 CPU 时间片。如果临界区执行时间过长，大量线程全部在自旋，CPU 会烧到接近 100%，但实际有效工作什么都没干。这是资源浪费最严重的一种同步方式误用。

// Java 的 AtomicInteger 和 CAS 操作就是典型的无锁/自旋思路 import java.util.concurrent.atomic.AtomicInteger; public class SpinExample { private AtomicInteger count = new AtomicInteger(0); public void increment() { count.incrementAndGet(); } }

JVM 里的synchronized其实也用了类似的思路。偏向锁、轻量级锁的本质就是在低竞争场景下先用 CAS 自旋尝试获取锁，如果竞争加剧再升级为重量级锁（阻塞）。这也是为什么大家在很多场景下用synchronized不会觉得性能太差的底层原因。

实战中心得：自旋锁的适用条件非常明确——临界区只有几条指令、锁持有时间远小于线程切换时间。对应到业务代码里，就是那种“只改一个标志位”“只更新一个计数器”“只做一次指针交换”的场景。如果临界区里出现了 IO 操作、网络请求、甚至稍微复杂的计算，那千万不要用自旋锁。

2.3 读写锁：读多写少场景的利器

很多业务场景的特点是：读操作非常频繁，写操作偶尔发生。如果所有读线程之间也互相排斥，那就白白损失了并发性。读写锁就是为了解决这个问题设计的。

读写锁允许多个读线程同时持有锁，它们可以并行读取共享资源。只有在写线程试图获取锁时，才会阻塞后续的读线程，保证写操作独占访问。这样既保证了写入时的数据一致性，又允许读取时的高并发。

#include <pthread.h> pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER; void read_data() { pthread_rwlock_rdlock(&rwlock); // 读取共享数据 pthread_rwlock_unlock(&rwlock); } void write_data() { pthread_rwlock_wrlock(&rwlock); // 修改共享数据 pthread_rwlock_unlock(&rwlock); }

读写锁在实现上一般会维护两个队列：读者队列和写者队列。这里有一个经典的策略问题：如果读线程源源不断地进来，写线程会不会永远等不到锁？这就是“读者优先”和“写者优先”之争。

• 读者优先策略：只要还有读线程在访问，写线程就持续等待。吞吐量高，但写线程可能饿死。
• 写者优先策略：一旦有写线程申请锁，新到达的读线程必须排队等待。写操作的延迟可控，但读吞吐量会下降。

实际使用中，多数实现会倾向于避免写线程饿死。比如某些实现里，如果写线程已经等了很长时间，即使当前持有锁的是读者，也会限制新读者入场。这块细节在不同语言、不同库里的行为不一致，高并发场景下做选型时值得专门查文档确认。

注意：读写锁并不是万能的。如果写操作占比超过 20%-30%，读写锁的优势会大幅缩小，因为锁维护和调度本身的复杂度比普通互斥锁高，写多读少场景下性能甚至不如直接用互斥锁。另外，读写锁在读多写少但读操作非常频繁的场景，也有可能出现 cache line 伪共享问题，这点后面详聊。

2.4 条件变量与信号量：从互斥走向协作

互斥锁、自旋锁、读写锁解决的都是"互相排斥"的同步问题。但实际业务里还有一种更常见的需求：一个线程完成了某个任务，需要通知其他线程继续执行。比如生产者生产了数据，要通知消费者来取；主线程完成了初始化，要通知工作线程开始干。这就是条件变量和信号量的舞台。

条件变量的核心用法是配合互斥锁使用：线程先加锁，然后检查条件，如果条件不满足就把自己阻塞在条件变量上并释放锁，等别的线程修改条件并发出通知后再被唤醒。

#include <pthread.h> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; int ready = 0; void *producer(void *arg) { pthread_mutex_lock(&mutex); ready = 1; pthread_cond_signal(&cond); // 唤醒等待线程 pthread_mutex_unlock(&mutex); return NULL; } void *consumer(void *arg) { pthread_mutex_lock(&mutex); while (!ready) { pthread_cond_wait(&cond, &mutex); // 等待条件满足 } // 条件满足，继续执行 pthread_mutex_unlock(&mutex); return NULL; }

这里有个非常重要的编程细节：条件变量等待时必须在循环里检查条件，不能用 if 替代 while。原因是多线程环境下可能存在“虚假唤醒”——线程被唤醒了，但实际条件并没有满足或已经被其他线程抢先消费。循环检查能兜住这种边界情况，这是无数 bug 的教训总结出来的经验。

信号量是另一种同步原语，它维护一个计数器，支持两种原子操作：wait（P 操作）将计数器减一，如果结果为负则阻塞；signal（V 操作）将计数器加一，唤醒一个被阻塞的线程。信号量既能用于互斥（初始化为 1），也能用于资源计数（初始化为 N），还能用于线程协作。

我个人的体会是：大多数人平时写代码用互斥锁和条件变量就够了。信号量适合的场景更偏向资源池管理、生产者消费者队列这种需要精确控制"最多 N 个线程同时访问"的场景。不去过度设计、选择语义最贴合的同步原语，代码的可维护性会好很多。

2.5 同步方式的选型对比

把几种主流线程同步方式放到一张表里对比，选型时可以对照着看：

选型决策只需要按三步走：先判断这个共享资源的访问特征是读为主还是写为主，再估算临界区的执行时间量级，最后结合并发线程数决定。临界区在纳秒到微秒级别、并发线程不太多，优先自旋；临界区有 IO 操作、执行时间在毫秒级以上，优先互斥锁；读多写少且读并发要求高，考虑读写锁或读时无锁方案；涉及线程间任务协作，直接上条件变量或消息队列。

3. 线程同步的实战问题与避坑

3.1 锁粒度与伪共享问题

锁粒度是性能调优里最容易被忽视却影响最大的因素。锁粒度太粗，很多无关操作都被串行化，并发能力被白白浪费；锁粒度太细，锁操作的次数变多，锁本身的开销变成新的瓶颈。

我见过一个真实案例：某个服务里有一个共享的配置对象，每次请求进来都要读几十个字段，代码直接给整个对象的读取方法加了大锁，结果所有读请求全部串行。后来改成把配置拆成多个独立字段，每个字段一个读写锁，并发能力立刻提升了几倍。这就是典型的需要关注锁粒度优化的场景。

还有一个问题需要特别提醒——伪共享（False Sharing）。现代 CPU 的缓存是按 cache line（通常 64 字节）加载的，如果两个线程各自操作不同的变量，但这两个变量恰好落在同一个 cache line 里，那么一个线程修改自己的变量时，会把这个 cache line 标记为无效，另一个线程读取自己变量时不得不重新从内存加载。这就像两个人各写各的作业，但偏偏共用一个桌面，一个人翻东西就会打扰到另一个人。

解决伪共享的思路也很直接：通过内存对齐或者 padding 让不同线程修改的变量落到不同的 cache line 上。Java 里有@Contended注解可以做到，C/C++ 里可以用alignas(64)或者在结构体里填充字节。

3.2 死锁的四种条件与排查思路

死锁是线程同步里最经典也最危险的坑。四个必要条件，缺一不可：互斥条件（资源同一时刻只能被一个线程持有）、持有并等待（线程持有资源 A 又在等待资源 B）、不可剥夺（资源不能被强制拿走）、循环等待（每个线程都在等待对方持有的资源）。

从工程角度说，打破任何一个条件都能防止死锁。最容易入手的是打破“循环等待”：给所有锁排序，所有线程都按相同顺序获取锁。比如有两把锁lock_a和lock_b，规定必须先拿lock_a再拿lock_b，就不会出现 A 线程持有lock_a等lock_b、B 线程持有lock_b等lock_a的循环。

排查死锁的经验，推荐三步走：第一步看线程堆栈，Java 用jstack，C/C++ 用gdb或 core dump，核心是找到锁之间互相等待的环。第二步看锁的持有路径，加一个锁申请顺序的日志记录，通过分析日志发现反向加锁的代码路径。第三步，如果问题非常隐蔽，可以考虑用专门工具，比如 Java 的 JFR 或动态追踪工具。

3.3 线程同步性能排查的真实记录

有一次排查一个网关服务的性能问题，QPS 上不去，CPU 使用率却已经打到 90% 以上。用perf抓热点，发现最热函数是内核里的futex_wait，大量线程在等锁时进入睡眠再唤醒，互相争抢同一个锁。

定位到具体代码后发现，一个 HTTP 请求处理链路里，有个全局的 URL 映射表，每个请求进来都要查这张表。表本身是只读的，但代码里每次查询都加了互斥锁，导致所有请求全部串行。修复方案是把互斥锁改成读写锁，读路径并发执行，写路径只在发布新配置时短暂触发。改完之后 QPS 提升了 3 倍多，CPU 降到了 30% 以下。

这个案例给到两条经验：一是只读路径能不加锁尽量不加锁，一定要用读锁而不是互斥锁；二是 aviod 无差别地给方法加锁，先通过 profile 工具确认热点，再针对性地调整同步策略。

4. 页面置换算法核心机制与原理

4.1 缺页中断与页面置换的起点

要说清楚页面置换算法，得先建立两个概念：虚拟内存和缺页中断。操作系统给每个进程分配虚拟地址空间，实际物理内存有限，两者之间通过页表映射。进程访问的页面如果不在物理内存中，CPU 会触发缺页异常，操作系统把需要的页面从磁盘加载到内存，这个过程叫缺页中断。

当内存已经放满，还要调入新的页面时，就必须把某个旧页面换出去，腾出位置。选哪个页面换出去，这就是页面置换算法要回答的问题。

这里有两个核心指标：缺页率和置换代价。缺页率越低，程序运行越顺畅；置换代价越低，系统资源消耗越少。但这两者在实际中往往是矛盾的：追求低缺页率就要维护更复杂的统计信息，置换代价随之上升；追求低成本就不太容易保证缺页率最优。

判断一个置换算法好不好，通常用 Belady 异常现象来检验：随着物理页框的增多，缺页次数反而增加的异常行为称为 Belady 异常。FIFO 是经典的会产生 Belady 异常的算法，而 LRU 在理论上不会发生这种现象。这个差异本身就是判断算法优劣的重要依据。

4.2 FIFO 与 OPT：最简单和最理想的两个极端

FIFO（先进先出）是最直观的算法：哪个页面最早进入内存，就先把哪个换出去。实现只需要一个先进先出的队列，每个页面进入内存时入队，缺页需要置换时出队队首。

FIFO 的问题在它完全不考虑页面的访问频率和访问时间。一个进程启动时加载的初始化代码，可能在运行中还要反复使用，但 FIFO 会毫不留情地把它们换出去。于是在某些访问序列下，FIFO 的缺页率不仅差，还会出现 Belady 异常。

与 FIFO 相对的是 OPT（最优置换算法）：每次都选择“未来最长时间不会被访问”的页面换出。这个算法理论上能保证最少的缺页次数，但它要求预知进程未来的页面访问序列，这在真实运行环境中是不可能的。所以 OPT 只能作为理论研究中的上界参考——其他算法再好，也不可能优于 OPT 的缺页结果。

实际工程里，几乎所有内存和缓存淘汰策略都是在逼近 OPT，只不过各家用不同的方法预测“未来最可能不被访问的页面”。预测的依据基本都来自历史访问模式：最近访问过的页面大概率还会再被访问。

4.3 LRU 与近似 LRU：理论最优与工程折中

LRU（最近最久未使用）是应用最广的页面置换算法之一。它的逻辑是：如果一个页面最近被访问过，那在不久的将来它很可能还会被访问；反之，最长时间没被访问的页面，大概率以后也不会再用，优先换出。

完全实现 LRU 需要记录每个页面最后一次访问的时间，并且每次访问都要更新这个信息。在硬件层面，给每个页表项维护一个时间戳已经是非常昂贵的操作了，更不用说在每纳秒级别的 CPU 操作中跟上这个更新频率。所以教科书里会说 LRU 是最接近 OPT 的算法，但是工程实现成本很高。

因此出现了大量 LRU 的近似实现。最常见的方案是 clock 算法（也叫时钟算法）：维护一个环形链表，每个页面有一个引用位。页面被访问时，引用位置 1。发生缺页需要置换时，从指针当前位置顺时针遍历，如果引用位为 1 就改成 0 并继续向下；如果找到引用位为 0 的页面，就换出它。

Clock 算法的妙处在于它只用了一个 bit 就近似了 LRU 的“最近使用”信息，代价是可能换出最近仍被使用的页面，但概率和偏差都控制在一个可接受的范围。Linux 内核里实际使用的也是基于 clock 思想的改进版本，兼顾了效率和硬件成本。

4.4 页面置换算法对比与工程选型

LFU（最不经常使用）统计的是“访问频率”而不是“最近访问时间”。在有些访问模式下 LFU 的表现优于 LRU，比如一个稳定的热点会被反复访问，LFU 能很好地保住这个热点，而 LRU 在某些场景下会因为偶发的批量访问导致热点被挤出去。但是 LFU 也不是没有自己的问题，它容易积累历史权重，导致一个新的热点很难把老的页面挤掉。实际工程里，Redis 的 allkeys-lfu 策略对这一点做了特殊处理——引入了衰减机制，让旧数据的访问频率随时间逐步降低，这才解决了老热点僵死的问题。

选型角度看心里要非常清楚：对于临时性很强的访问（比如一次扫描、一次编译），FIFO 或近似算法够用；对于长期服务型进程，LRU 和 Clock 是更稳妥的选择；对于有明显热点模式的缓存型负载，LFU 或者带衰减的 LFU 变体效果更好。没有银弹，看场景对号入座。

5. 页面置换在真实世界的映射

5.1 操作系统中的页面置换：从原理到落地

现代操作系统很少直接让一个用户进程触发传统的全量页面置换，但问题并没有消失，只是层级变了。Linux 内核中负责内存回收的机制，本质上就是在做页面置换决策，只是它的换出对象、触发时机和算法远比教科书里的描述复杂。

Linux 的页面回收会给每个页面维护一个 active 列表和一个 inactive 列表，页面在两列表之间迁移，效果上就是近似 LRU 的多级队列实现。它会优先回收 inactive 列表里的页面，尽量避免把活跃数据换出。这个设计思路跟 clock 算法有异曲同工之妙，只不过区分度更高、抗扫描能力更强。

对普通开发者来说，这一层的实际应用点是理解 RSS 和内存水位线。当一个进程的内存占用触碰到系统内存水位线时，内核会启动内存回收，可能导致进程的匿名页被 swap 到磁盘，下次访问时再换回来。如果 swap 配置不当或者内存压力持续增高，系统的缺页率和 IO 负载都会飙升，表现为服务响应延迟抖动、性能骤降。

提示：如果服务器上开启了 swap，而且你观察到系统负载很高但 CPU 利用率不高，大概率是 swap 频繁导致的。检查vmstat里的si和so两个字段，数值大说明换入换出非常频繁，这时候优先考虑的是增加内存或优化业务的内存占用，而不是调 swap 参数。

5.2 缓存系统里的淘汰策略：Redis 和数据库场景

页面置换算法这个概念在操作系统层面是页面，在应用层就是缓存条目。Redis 的内存淘汰策略就是页面置换算法思想的直接应用，而且是生产环境里最容易验证算法优劣的战场。

Redis 支持多种淘汰策略，和本文主题相关的有allkeys-lru、allkeys-lfu、volatile-lru、volatile-lfu、allkeys-random等。LRU 策略在 Redis 的实现里不是严格的 LRU，而是近似 LRU——它采样一部分 key（默认 5 个），从中找出最近最少使用的淘汰。这样既避免了全局排序的开销，又能在采样足够多的情况下接近真实 LRU 的效果。

在 LFU 模式下，Redis 维护了一个 24 位的计数器来记录 key 的访问频次，并且引入了时间衰减机制。这个衰减机制是关键的工程细节：如果只统计总访问次数，历史热点会永远占着位置，新的热点进不来。加了衰减之后，长期不访问的 key 的计数会降低，最终让位给新的热点数据。用的时候在配置文件里设置maxmemory-policy allkeys-lfu并把lfu-decay-time和lfu-log-factor调到一个合适的比例，就能很好地应对业务中的数据冷热变化。

数据库的 buffer pool、本地进程的缓存组件、CDN 边缘节点的内容淘汰，本质上都在用类似的策略。理解了页面置换算法的取舍逻辑，再看这些组件的配置选项，就会觉得非常熟悉。

5.3 一次缓存命中率调优的实战复盘

去年调一个查询服务，接口响应时间一直不稳定。通过监控发现 Redis 的miss ratio经常冲到 40% 以上，每次 miss 都要回源到数据库，把数据库打得很疼。

梳理访问模式后发现，数据有明显的冷热分层：大约 20% 的热 key 贡献了 80% 的访问量，还有一些周期性访问的数据，比如整点任务集中跑一批，过后就长时间不访问。原来的配置用的是allkeys-lru，在这种访问模式下，周期性的批量访问很容易把热 key 挤出去，导致热 key 频繁回源。

调整方案分两步。第一步把策略改成allkeys-lfu，并设置lfu-decay-time 1，让低频数据快速降温。第二步给热 key 方向加一个主动续期任务，对核心热 key 提前刷新过期时间，减少 miss 触顶的窗口。上线后 hit ratio 从 68% 拉到了 91%，数据库压力骤降，接口 P99 延迟从 120ms 压到了 30ms。

这个案例给到的重要启发：淘汰策略的选型不能只看算法名，要结合访问模式的周期性、正态性来选择。类似"一群冷数据集中访问一轮"的扫描型负载，LRU 会误伤热数据；LFU 也会因为衰减不及时导致热点转移缓慢。没有全能的算法，只有对业务访问画像的深刻理解。

6. 常见问题与排查技巧实录

整理一下这两年排查线程同步和页面置换相关问题时最高频的几类情况，做成速查表方便直接对照：

针对几个高频排查场景，再补充一些实操经验。

第一个场景是锁竞争导致性能骤降。遇到这种情况，先别急着换锁的类型，先用 profile 工具定位到具体的锁，看看是哪个锁的 wait 时间最长。Java 里可以用jstack抓线程 dump，看大量线程集中在哪个锁的waiting to lock行；C/C++ 程序可以用perf lock report直接分析锁的竞争情况。定位到了之后再决定是改同步方式、减少锁粒度，还是用无锁数据结构替换。

第二个场景是内存压力的诊断顺序。我一般这样处理：先看free -h确认内存整体水位，再看vmstat的 si/so 判断是否在频繁 swap，如果确认在 swap 就用sar -B查看 pgpgin/pgpout 的具体速率，定位到是有多少系统在参与换页。然后排查业务侧：哪些进程在吃内存，缓存组件的淘汰策略是什么，有没有存在内存泄漏的代码路径。这个顺序能最快地缩小问题范围。

第三个场景是缓存淘汰策略调参。不管用 LRU 还是 LFU，都不要直接跳到生产环境改配置，先在测试环境用真实流量回放跑一段时间，观察 miss 率、内存使用、QPS 三个指标在策略切换前后的变化。实测下来，maxmemory-samples这个参数对 Redis 近似 LRU 的效果影响很大，采样数从 5 调到 10 通常能明显提升命中率，但也会增加一点点淘汰计算的耗时，需要根据机器性能平衡。

这里分享一个个人很常用的调参经验：核心原则是“小步调、看趋势”。每次只改一个参数，观察至少一个业务周期（如果业务有早高峰晚高峰，就观察完整的一天），收集数据后再决定下一轮是否继续调整。切忌一次改多个参数，否则出了问题根本无法定位是哪个改动导致的。

最后分享一条踩坑多年的体会：线程同步和页面置换，一个是并发视角、一个是内存视角，但它们最终都指向同一个性能调优原则——理解资源的竞争特征，再用最小的代价换取最大的确定性。加锁能解决一致性问题，但必须以合理的锁粒度和匹配的同步原语为代价；缓存淘汰能解决内存压力，但必须以理解业务的访问模式为前提。技术选型的核心从来不是选最复杂的方案，而是选那个和你的场景最贴合、在性能和可靠性之间平衡得最好的方案。遇到难缠的性能问题，先跳出代码看一眼架构，往往更容易找到那个被忽略的瓶颈。