某个系统上线后出现连接池耗尽，如何一步步排查。可能还需要引用知识库中的具体配置示例，比如HikariCP的配置参数，或者Druid的监控方法。

遇到了线上连接池耗尽的问题，想要了解如何快速定位和解决。

## 问题背景

某核心业务系统上线后，用户反馈访问缓慢，部分接口出现超时甚至报错。通过监控平台查看，发现服务端异常日志中频繁出现如下错误：

```
text

Caused by: java.sql.SQLTransientConnectionException: 
HikariPool-1 - Connection is not available, request timed out after 30000ms.
```

这表明 数据库连接池资源已经耗尽，请求无法获取数据库连接，导致服务不可用。

## 排查思路与实战分析

### 确认问题表现

**接口响应超时、数据库连接超时异常（如 SQLTransientConnectionException）**。

监控指标：

* 数据库连接池的 Active Connections 接近或达到最大值。
* 连接池的 Wait Queue 长度持续增长。
* 数据库服务器的 CPU、内存或磁盘 I/O 负载过高。

### 初步定位原因

* 连接池配置不足：最大连接数（maximumPoolSize）设置过低，无法满足高并发需求。
* 连接未释放：代码中存在未正确关闭数据库连接（如未调用 connection.close()）。
* 慢查询阻塞：SQL 查询执行时间过长，占用连接资源。
* 事务未提交：事务长时间未提交或回滚，导致连接被锁定。
* 连接泄漏：应用层代码逻辑错误导致连接未归还连接池。

### 详细排查步骤

#### 检查连接池配置

HikariCP 配置示例：

```
yaml

spring:
  datasource:
     hikari:
      #最小空闲连接，默认值10
      minimum-idle: 5
      # 连接池大小及超时等配置
      maximum-pool-size: 20
      # 空闲连接超时时间，
      idle-timeout: 30000
      # 连接超时时间
      connection-timeout: 30000
      pool-name: pool-1
```

#### 分析连接池使用情况

监控工具：

* Prometheus + Grafana：实时监控连接池的 Active Connections、Idle Connections 和 Wait Queue。
* Druid 内置监控：通过 /druid 管理页面查看连接池状态。
* HikariCP 统计：通过 JMX 查看 HikariPool 的 TotalConnections 和 ConnectionsAcquired。

关键指标：

* Active Connections：当前正在使用的连接数。
* Wait Queue：等待获取连接的请求数。
* Connection Timeout：获取连接的超时次数。

#### 检查数据库操作代码

代码审查重点：

* 是否关闭连接：确保每次数据库操作后调用 connection.close()。
* 是否使用事务：事务未提交或回滚会导致连接被锁定。
* 是否复用连接：避免在循环中频繁创建新连接。

问题代码：

```
java

@Resource
private PlatformTransactionManager transactionManager;

public void queryData() {
    TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());
    // 代码异常，导致没有提交与回滚
    ....
    try {
    
    } catch (Exception e) {
        transactionManager.rollback(transaction);
    } finally {
        if (Objects.nonNull(transaction) && transaction.isNewTransaction() && !transaction.isCompleted()) {
         transactionManager.commit(transaction);
        }
    }
}
```

#### 分析慢查询日志

MySQL 慢查询日志：

```
sql

SHOW VARIABLES LIKE 'slow_query_log';
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 执行时间超过 1 秒的查询记录日志
```

#### 排查连接泄漏

工具辅助：

* Arthas：通过 trace 命令定位未释放连接的代码路径。
* JVM 堆栈分析：通过 jstack 分析线程堆栈，查看连接被哪些线程占用。

示例命令：

```
sh

jstack <pid> | grep "HikariPool" -A 20  # 查找连接池相关线程
```

## 其他同类问题

### 线程阻塞 / 死锁 / 活锁

现象： 请求卡死无响应，线程数居高不下，CPU 可能不高但吞吐为零或极低。

### 排查思路：

* jstack 分析线程状态：

  + BLOCKED (on object monitor)： 明显锁竞争。查找持有锁的线程和等待锁的线程堆栈，定位竞争资源。
  + WAITING (parking, on condition, on monitor) / TIMED\_WAITING： 等待条件满足（如 Object.wait(), Condition.await()）或 I/O 操作。检查是否条件未唤醒或 I/O 超时。
* 死锁检测： jstack 输出末尾通常会报告 Found one Java-level deadlock，列出死锁线程和锁信息。分析相关代码的同步逻辑。
* 检查锁使用： 是否过度使用 synchronized 或粗粒度锁？是否该用并发集合 (ConcurrentHashMap) 或更高级的锁 (StampedLock, ReadWriteLock)？
* 资源等待： 数据库连接池耗尽、HTTP 连接池耗尽、文件句柄耗尽等也会导致线程阻塞。检查相关资源池状态。

注意

数据库连接池耗尽、HTTP 连接池耗尽、文件句柄耗尽等也会导致线程阻塞，需要检查相关资源池状态。

## 总结与建议

### 总结

DB 连接池耗尽问题的核心在于 连接资源管理不当，需从配置、代码、数据库优化和监控四个方面综合解决。

### 建议

* 合理配置连接池参数：根据业务负载动态调整 maximumPoolSize 和超时时间。
* 严格遵循编码规范：确保每次数据库操作后关闭连接，避免泄漏。
* 定期分析慢查询日志：优化高频 SQL，减少数据库负载。
* 引入监控与告警：实时掌握连接池状态，及时发现潜在问题。

线上性能问题 - 连接池耗尽的排查思路

生产环境黄金法则：当JVM出现异常时，命令行工具是比可视化界面更可靠的诊断手段。本文将深入解析JVM核心命令行工具，助你成为线上问题排查专家。

## JVM命令行工具全景图

不同的命令有不同的使用场景，根据要分析的内容选择合适的命令工具，注意其中的开销对性能的影响。

| JVM工具命令 | 使用场景 | 生产适用性 | 执行开销 |
| --- | --- | --- | --- |
| jcmd | 综合诊断 | ⭐⭐⭐⭐⭐ | **极低** |
| jstack | 线程分析 | ⭐⭐⭐⭐ | 低 |
| jmap | 内存分析 | ⭐⭐⭐ | 中高 |
| jstat | GC监控 | ⭐⭐⭐⭐⭐ | **极低** |
| jinfo | 参数查看 | ⭐⭐⭐ | 低 |

## 核心工具详解与实战示例

### jcmd：全能诊断工具

`jcmd` 是 Oracle JDK（Java Development Kit）自 JDK 7 起引入的一个强大的诊断工具，用于与正在运行的 JVM（Java Virtual Machine）实例进行交互。它允许用户执行各种诊断命令，比如 **线程堆栈分析、堆转储、GC 信息、类加载器统计** 等，非常适合在生产环境中对 Java 应用程序进行调试和监控。

```
sh

# 语法
jcmd <pid | main class> <command ...|PerfCounter.print|-f file>
```

* `<pid>`: 目标 Java 进程的进程 ID。
* `<main-class>`: 目标 Java 应用的主类名（可以省略 jar 路径）。
* `<command>`: 具体的诊断命令，如 VM.version、Thread.print、GC.heap\_info 等。
* `[options]`：命令附带的参数（具体取决于命令）。

```
sh

# 查看所有支持的命令
jcmd <pid>
jcmd <pid> help
```

展示所有命令信息：

![image.png](https://blog.liushigong.cn/static/img/08238a0c3ba4e8fcdbdb6ef200ba1df2.image.webp)

具体用法：

```
sh

# 查看JDK版本
jcmd <pid> VM.version

# 查看启动参数
jcmd <pid> VM.command_line

# 强制触发 GC
jcmd <pid> GC.run

# 查看内存统计，显示堆占用情况（老年代、新生代等）。
jcmd <pid> GC.heap_info

# 检查是否发生了死锁，如果存在死锁，会提示 Found one Java-level deadlock
jcmd <pid> Thread.print

# 生成线程快照（替代jstack），用于诊断死锁或高 CPU 问题。
jcmd <pid> Thread.print > thread_dump.txt

# 生成堆转储文件（替代jmap），用于分析内存泄漏或对象分布。
jcmd <pid> GC.heap_dump ./dump.hprof

# 获取类加载统计，显示堆中存活对象的数量及内存占用，按类排序。
jcmd <pid> GC.class_histogram
```

提示

查询java进程信息

```
sh

jps -l
```

查找类加载统计，包含包路径的前10条记录

```
sh

jcmd 7 GC.class_histogram | grep 'com.liushigong' | head -n 10
```

查询死锁信息

```
sh

jcmd 7 Thread.print | grep 'Found one Java-level deadlock' -A 20
```

查询状态为阻塞的线程

```
sh

jcmd 7 Thread.print | grep 'BLOCKED' -A 20
```

### jstack：线程分析利器

jstack 是 JDK 提供的一个命令行工具，用于生成 Java 虚拟机（JVM）的线程转储（Thread Dump）.通过分析线程转储，可以快速定位死锁、线程阻塞、CPU 占用过高等问题。

线程转储是 JVM 中所有线程状态的快照，包含以下关键信息：

* 线程的调用栈（Stack Trace）
* 线程的状态（RUNNABLE、BLOCKED、WAITING 等）
* 锁信息（持有的锁或等待的锁）
* 线程优先级和所属线程组

```
sh

# 语法
jstack [options] <pid>
jstack [options] <executable> <core>
jstack [options] [server_id@] <remote server IP or hostname>
```

* -l 或 --long：输出详细的锁信息，包括哪些线程持有锁和哪些线程在等待锁。
* -F 或 --force：强制生成线程转储，适用于进程无响应的情况。
* -m 或 --mixed：显示混合模式的堆栈信息，即同时显示Java代码和本地代码的堆栈信息。
* -h 或 --help：显示帮助信息，列出所有可用的命令行选项。
* -V 或 --version：显示jstack的版本信息。

```
sh

# 基础线程快照
jstack <pid> > thread_dump.txt

# 包含锁信息（-l参数）
jstack -l <pid> > locked_threads.txt

# 追踪死锁（结合grep）
jstack <pid> | grep -A 1 deadlock

# 查找BLOCKED状态的线程，有助于快速定位可能存在线程阻塞或死锁的问题。
jstack -l [pid] | grep "BLOCKED"

# 远程调试，需要指定远程服务器的IP或主机名。
jstack [server_id@] <remote server IP or hostname>
```

**关键信息解读：**

```
java

"main" #1 prio=5 os_prio=0 tid=0x00007f8b4800e800 nid=0x1a03 waiting on condition [0x00007f8b50a0e000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x000000076b8a1c98> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
    at com.example.MyService.doSomething(MyService.java:42) // 定位到源码行
```

**适用场景：**

1. 诊断死锁：当Java应用程序出现死锁时，可以使用jstack命令打印线程堆栈信息，并分析哪些线程在等待哪些资源。通过分析这些信息，可以找出死锁的原因并解决它。
2. 分析性能问题：当Java应用程序出现性能问题时（如响应时间过长、CPU使用率过高等），可以使用jstack命令获取线程堆栈信息，并查看哪些线程在执行哪些操作。这有助于找出性能瓶颈并进行优化。
3. 监控线程状态：使用jstack命令可以实时监控Java应用程序的线程状态，包括正在运行的线程、等待的线程以及阻塞的线程等。这有助于了解应用程序的运行状态并进行相应的调整。
4. 分析core dump文件：当Java应用程序崩溃并生成core dump文件时，可以使用jstack命令分析该文件并获取崩溃时的线程堆栈信息。这有助于找出崩溃的原因并进行修复。

注意

执行时 JVM 会有短暂停顿（Safepoint）

### jmap：内存分析专家

```
sh

# 堆直方图（安全）
jmap -histo:live <pid> > histo.txt

# 堆转储（谨慎使用）
jmap -dump:live,format=b,file=heap.hprof <pid>

# 内存使用概况
jmap -heap <pid>
```

注意

使用 jmap 命令时需要注意以下几点：

* `-dump:live` 会触发 Full GC
* 大堆（>8GB）转储可能导致服务暂停，使用替代方案 `jcmd <pid> GC.heap_dump ./dump.hprof`

**适用场景：**

1. 内存泄漏检测：使用 jmap 可以帮助识别内存泄漏。通过生成堆的内存映射，开发者可以查看哪些对象没有被垃圾回收器回收，从而确定内存泄漏的源头。
2. 堆内存使用分析：分析堆内存的使用情况，包括各个对象的大小和数量，可以帮助开发者理解内存消耗的模式，并据此优化应用程序的内存使用。
3. 对象分配统计：jmap 可以提供关于堆中对象分配的统计信息，这有助于了解哪些类的实例化最频繁，哪些类消耗了最多的内存。
4. 堆转储：虽然 jmap 本身不直接支持实时堆转储（类似于 `jmap -dump:live,format=b,file=heapdump.hprof`），但可以通过 jmap 生成整个堆的快照（尽管这通常需要暂停应用程序的运行）。这对于后续使用如 Eclipse Memory Analyzer (MAT) 等工具进行详细分析非常有用。
5. 类加载器统计：查看类加载器的统计信息，了解哪些类被加载，以及它们占用的内存量，有助于优化类的加载策略。
6. 直方图生成：jmap -histo 命令可以生成一个堆中对象的直方图，显示每个类的实例数量和总大小，这对于识别占用大量内存的对象类型非常有帮助。

生产环境安全操作

随着 JDK 的发展，一些新的工具如 jcmd（通过 `jcmd <pid> VM.native_memory` 和 `jcmd <pid> GC.class_histogram`、`jcmd <pid> GC.heap_dump ./dump.hprof`）提供了类似的功能，且不会暂停应用程序运行。

```
sh

# 1. 设置OOM自动转储（避免手动执行）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path

# 2. 使用低开销替代方案
jcmd <pid> GC.class_histogram > histo.txt
jcmd <pid> GC.heap_dump ./dump.hprof
```

### jstat：GC监控神器

jstat (Java Virtual Machine Statistics Monitoring Tool) 是用于监控和分析 Java 虚拟机 (JVM) 性能的工具。它提供了 JVM 的运行时信息，比如垃圾收集的状态、内存使用情况、类加载信息等。jstat 是 JDK 中自带的命令行工具，可以帮助开发者和运维人员排查和优化 JVM 性能问题。

```
sh

# 语法
jstat [option] [vmid] [interval] [count]
```

* option‌：指定要查看的统计信息类型。
* vmid‌：JVM实例的进程ID（PID）。
* interval‌（可选）：每次输出的时间间隔，单位为毫秒。
* count‌（可选）：输出的次数。

```
sh

# 每2秒打印GC情况（持续监控）
jstat -gcutil <pid> 2000

# 每2秒打印GC原因
jstat -gccause <pid> 2000
```

![image.png](https://blog.liushigong.cn/static/img/f7e36bf1c7506128271e5fbb7a984c6b.image.webp)

* S0 — Heap上的 Survivor space 0 区已使用空间的百分比
* S1 — Heap上的 Survivor space 1 区已使用空间的百分比
* E — Heap上的 Eden space 区已使用空间的百分比
* O — Heap上的 Old space 区已使用空间的百分比
* P — Perm space 区已使用空间的百分比
* YGC — 从应用程序启动到采样时发生 Young GC 的次数
* YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
* FGC — 从应用程序启动到采样时发生 Full GC 的次数
* FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
* GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
* LGCC - 进行GC的原因（低版本jdk可能没有这一列）

**关键指标解读：**

* O：Old 区使用率 >80% 需告警
* FGC：Full GC次数，每小时>2次异常
* FGCT：Full GC耗时，>1秒需优化

**适用场景：**

* 监控垃圾收集性能：使用 jstat 可以查看垃圾收集器的行为，包括垃圾收集的次数、垃圾收集花费的时间等。这对于优化垃圾收集器的选择和配置非常有用。
* 监控堆内存使用情况：查看堆内存的使用情况，包括年轻代、老年代的大小和已使用量，这对于诊断内存泄漏和调整堆大小非常关键。
* 分析 JVM 的总体性能：结合多个 jstat 选项，可以获取 JVM 的多方面性能数据，如 CPU 使用率、内存使用情况、垃圾收集活动等。
* GC参数调优验证：通过监控和分析 jstat 提供的数据，开发者可以调整 JVM 的参数，如堆大小、垃圾收集策略等，以优化应用程序的性能。
* 故障诊断：当应用程序遇到性能问题或内存泄漏时，jstat 可以帮助确定问题的根源，例如是否是由于垃圾收集频繁导致的问题，或者是内存泄漏导致的问题。

### jinfo：JVM 参数查看与调整

查看当前 JVM 参数或动态修改部分参数（如日志级别）。

```
sh

jinfo [option] <pid>
```

* `-flag <name>`: 获取指定参数的值。
* `-flag [+|-]<name>`: 打开或关闭指定参数。
* `-flag <name>=<value>`: 设置指定参数的值。
* `-flags`: 打印所有JVM参数。
* `-sysprops`: 显示JVM的系统属性‌

```
sh

# 查看所有参数
jinfo -flags <pid>

# 查看单个参数值
jinfo -flag MaxHeapSize <pid>

# 动态修改参数（仅支持部分）
jinfo -flag +HeapDumpOnOutOfMemoryError <pid>
```

查看这个JVM进程查看和修改虚拟机的参数，但是修改的有限制的，只有manageble的参数才可以动态修改。其他的必须重启的时候设置修改。

```
sh

java -XX:+PrintFlagsFinal –version
```

![image.png](https://blog.liushigong.cn/static/img/7317cfb0e8c060dd4785705738ff53ad.image.webp)

**适用场景：**

* 监控和调试‌：在开发和调试阶段，jinfo可以帮助开发者了解JVM的配置情况，确保应用程序能够正常运行。通过查看JVM参数和系统属性，可以快速定位问题并进行调整‌
* 性能优化‌：在生产环境中，jinfo可以用于监控和诊断JVM的性能问题。通过分析JVM参数和系统属性，可以优化内存使用、线程管理和垃圾回收等，从而提高应用程序的性能和稳定性‌
* 参数调整‌：在需要对JVM参数进行调整时，jinfo可以提供当前进程的配置信息，帮助用户判断哪些参数需要调整以及如何调整。虽然jinfo不支持动态修改某些重要参数，但它仍然是调优过程中的重要工具‌

注意

注意生产环境慎用写操作

## 实战问题排查流程

### 案例1：CPU飙升200%

```
bash

# 1. 定位高CPU线程
top -H -p <pid>  # 记录线程ID(十进制)

# 2. 转换线程ID为十六进制
printf "%x\n" 11542  # -> 2d16

# 3. 抓取线程栈
jstack <pid> | grep -A 20 'nid=0x2d16'

# 4. 分析栈轨迹（发现死循环）
while (true) { calculate(); } // 定位问题代码
```

### 案例2：内存泄漏排查

```
bash

# 1. 监控GC趋势（发现Old区持续增长）
jstat -gcutil <pid> 1000 10

# 2. 获取堆直方图
jcmd <pid> GC.class_histogram > histo_day1.txt

# 3. 对比数据（8小时后再次抓取）
diff histo_day1.txt histo_day2.txt

# 4. 发现MyObject数量从1k增至5k
# 5. 生成堆转储分析引用链
```

## 堆转储深度分析指南

### 分析工具选择

| 工具 | 优势 | 适用场景 |
| --- | --- | --- |
| Eclipse MAT | 内存泄漏检测强大 | 复杂内存泄漏 |
| VisualVM | 直观易用 | 快速对象分析 |
| JDK Mission Control | 低开销采样 | 生产环境实时分析 |

### MAT分析实战步骤

泄漏嫌疑分析：

* 打开histogram视图
* 按Retained Heap排序
* 筛选项目自定义类

定位GC Roots：

```
java

// 示例：ThreadLocal泄漏
Thread @ 0x7fe45b88d 
-> ThreadLocalMap @ 0x7fe4a3f1021
-> MyObject @ 0x7fe4a3f1045 (1000个实例)
```

以上简述了分析流程，我将写一篇专门的MAT工具实战分析。

## 高级技巧：工具组合拳

### 内存泄漏终极排查

```
bash

# 1. 实时监控GC
watch "jstat -gcutil <pid> 1000 1"

# 2. 发现Old区增长后立即抓取
jcmd <pid> GC.heap_dump filename=leak.hprof

# 3. 同时获取线程栈
jstack <pid> > thread_state.log

# 4. 分析对象与线程关联
grep 'MyObject' thread_state.log -A 5
```

### 安全防护配置

```
bash

# 启动时预置诊断参数
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/logs/heapdumps \
     -XX:ErrorFile=/logs/hs_err_pid%p.log \
     -Xlog:gc*:file=/logs/gc.log
```

## 避坑指南：生产环境注意事项

### 堆转储安全操作：

1. 使用jcmd代替jmap减少影响，
2. 同时要避免在业务的高峰时段操作
3. 限制转储文件大小：`-XX:HeapDumpMaxFileSize=1g`

### 容器环境特殊处理：

```
bash

# 进入容器执行命令，查看服务的 pid
docker exec -it <container> jcmd

# 分析堆信息
docker exec -it <container> jcmd <pid> GC.heap_info

# Kubernetes诊断Pod
kubectl exec <pod> -- jstack 1 > thread.log
```

### 权限管理

* 使用相同用户运行JVM和工具
* 开启-XX:+PerfDataSaveToFile允许只读访问

## 工具组合建议与踩坑经验

| 问题类型 | 推荐工具组合 |
| --- | --- |
| CPU 飙高 | top + jstack + Arthas trace |
| 接口卡顿 | Arthas tt/watch/trace |
| 内存泄漏 | jmap + MAT + jstat |
| 类加载冲突 | jad, sc, classloader |
| 容器内调试 | Arthas 支持 docker 内 attach |

## 经验总结

线上性能问题，无非就2种，一种是CPU飙升，另一种就是内存打满，根据不同的问题类型使用不同的命令工具分析。90%的JVM问题可通过 **jcmd+jstack+jstat** 组合定位。

记住：优秀的开发者能写代码，卓越的工程师能救火！

性能优化 - JVM 命令行工具全解析与实战指南

“过早优化是万恶之源，但数据库优化除外” - 这次聚焦在数据库开发优化上，其中 **大事务** 是数据库性能的“头号杀手”，会重点展开，从识别、拆分、异步化几个角度切入，尤其要强调锁竞争和回滚风险。除了大事务，也包括一些其他优化点：索引设计、批处理、连接池调优、读写分离等等。

## 大事务处理：数据库的「不可承受之重」

### 典型事故场景（支付回调业务）

```
java

@Transactional // 默认60秒超时
public void payCallback(PayMessage msg) {
    // 1. 更新订单状态（锁订单行）
    orderDao.updateStatus(msg.getOrderId(), PAID);
    
    // 2. 生成会计凭证（耗时统计操作）
    accountingService.createEntries(msg); // 平均耗时45秒
    
    // 3. 发放用户权益（调用外部服务）
    benefitService.grantVoucher(msg.getUserId()); // 网络波动时超时
}
```

产生的影响: 订单表长期锁等待 → 支付服务线程池打满 → 整个支付链路瘫痪

### 破局方案：事务拆分四步法

1、业务解耦 - 异步化非核心操作

```
java

@Transactional
public void payCallback(PayMessage msg) {
    orderDao.updateStatus(msg.getOrderId(), PAID); // 仅保留核心事务
    
    // 异步化下游操作
    accountingAsyncService.createEntries(msg);
    benefitAsyncService.grantVoucher(msg.getUserId());
}
```

2、分而治之 - 拆分事务粒度

```
java

public void handleLargeBatch() {
    List<Data> batch = queryLargeData();
    for (int i = 0; i < batch.size(); i += 100) {
        // 每100条提交一次事务
        processBatch(batch.subList(i, Math.min(i+100, batch.size())));
    }
}

@Transactional(propagation = Propagation.REQUIRES_NEW) // 独立事务
public void processBatch(List<Data> batch) { ... }
```

3、 状态机管理 - 避免长事务锁

```
java

-- 设计中间状态字段
UPDATE orders 
SET status = 'PROCESSING' -- 非终态不阻塞查询
WHERE status = 'NEW' AND id = 10086;
```

4、妥协策略 - 最终一致性补偿

```
text

支付回调 -> 本地事务： 更新订单状态
本地事务 -> 消息队列： 发送会计事件
消息队列 -> 会计服务： 消费事件（可能重试）
会计服务 -> 支付回调： 处理失败? 
支付回调 -> 补偿服务： 触发补偿机制
```

## 索引优化：别让索引成为「摆设」

### 高频失效场景

```
sql

-- 案例：1.2亿用户表查询缓慢
SELECT * FROM users 
WHERE YEAR(create_time) = 2023  -- 索引失效！ 
   AND status = 1;
```

### 索引优化四原则

左匹配原则

```
sql

-- 重建联合索引（避免函数计算）
ALTER TABLE users ADD INDEX idx_status_ctime(status, create_time);

-- 正确查询姿势
SELECT * FROM users 
WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'
  AND status = 1;
```

覆盖索引降IO

```
sql

-- 避免回表查询
SELECT id, name FROM users 
WHERE phone = '13800138000'; 
-- 索引覆盖：INDEX(phone, name)
```

拒绝过度索引

```
sql

-- 索引代价测试（插入10w数据）
| 索引数量 | 插入耗时  |
|---------|----------|
| 0       | 1.2s     |
| 5       | 3.8s     |
| 10      | 8.5s     |
```

定期索引体检

```
sql

-- 使用诊断工具（MySQL示例）
EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 10086;

-- 清理无效索引
SELECT * FROM sys.schema_unused_indexes;
```

## 批处理艺术：拒绝SQL碎片

当下的计算机CPU处理速度还是很多的，而 IO 一般是个瓶颈，如：磁盘IO、网络IO。

有这么一个场景，查询 100 个人的账户余额？

有两个设计方案：

* 方案一：开单次查询接口，调用方内部循环调用 100 次
* 方案二：服务提供方开一个批量查询接口，调用方只需查询 1 次

你觉得那种方案更好？答案不言而喻，肯定是方案二

数据库的写操作也是一样道理，为了提高性能，我们一般都是采用批量更新。

## 创建100条数据

```
java

//创建商品的controller
@RequestMapping(value = "/create",method = {RequestMethod.POST})
@ResponseBody
public CommonReturnType createItem(@RequestParam(name = "title")String title,
                                   @RequestParam(name = "description")String description,
                                   @RequestParam(name = "price")BigDecimal price,
                                   @RequestParam(name = "stock")Integer stock,
                                   @RequestParam(name = "imgUrl")String imgUrl) throws BusinessException {
    //封装service请求用来创建商品
    ItemModel itemModel = new ItemModel();
    itemModel.setTitle(title);
    itemModel.setDescription(description);
    itemModel.setPrice(price);
    itemModel.setStock(stock);
    itemModel.setImgUrl(imgUrl);
    ItemModel itemModelForReturn = null;
    for(int i = 1 ;i <=100;i ++){
        itemModel.setId(null);
        itemModelForReturn = itemService.createItem(itemModel);
    }

    ItemVO itemVO = convertVOFromModel(itemModelForReturn);
    //rocketMQTemplate.convertAndSend("item-update-mq", itemModel.getId());

    bloomFilter.add("item_" + itemModel.getId());
    return CommonReturnType.create(itemVO);
}
```

## 单独查询100条

```
java

@RequestMapping(value = "/getItems",method = {RequestMethod.GET})
@ResponseBody
public CommonReturnType getItems(@RequestParam(name = "startId")Integer startId,@RequestParam(name = "endId")Integer endId){
    log.info("批量获取数据开始");
    List<ItemVO> itemVOs = new ArrayList<>();
    Date startTime = new Date();
    for(int i = startId;i <= endId; i++){
        ItemModel itemModel = itemService.getItemById(i);
        ItemVO itemVO = convertVOFromModel(itemModel);
        itemVOs.add(itemVO);
    }
    Date endTime = new Date();
    log.info("批量获取数据总共耗时：{}",startTime.getTime() - endTime.getTime());
    return CommonReturnType.create(itemVOs);
}
```

## 批量获取数据

```
java

@RequestMapping(value = "/getItemsByBath",method = {RequestMethod.GET})
@ResponseBody
public CommonReturnType getItemsByBath(@RequestParam(name = "startId")Integer startId,@RequestParam(name = "endId")Integer endId){
    log.info("批量获取数据开始");
    List<ItemVO> itemVOs = new ArrayList<>();
    Date startTime = new Date();
    List<ItemModel> itemModels = itemService.getItemsByBath(startId,endId);
    for (ItemModel itemModel : itemModels) {
        ItemVO itemVO = convertVOFromModel(itemModel);
        itemVOs.add(itemVO);
    }

    Date endTime = new Date();
    log.info("批量获取数据总共耗时：{}",endTime.getTime() - startTime.getTime());
    return CommonReturnType.create(itemVOs);
}
```

## 连接池调优：隐藏的资源黑洞

### 错误配置症状

* Connection timeout 频发
* 数据库连接数暴涨
* 服务重启后响应缓慢

### 关键参数黄金法则

```
yaml

# Spring Boot配置示例
spring:
  datasource:
    hikari:
      maximum-pool-size: 20   # = (核心数*2) + 磁盘数 
      minimum-idle: 5
      connection-timeout: 3000
      idle-timeout: 600000
      max-lifetime: 1800000
      connection-test-query: SELECT 1
```

### 动态调整策略

```
java

// 运行时热调整连接池
HikariPool pool = (HikariPool) dataSource.getHikariPoolMXBean();
pool.setMaximumPoolSize(30); // 应对流量高峰
```

## sql的排查优化

* 检查最长事务：

  ```
  sql

  SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 10;
  ```
* 对核心表执行 `EXPLAIN` 体检
* 事务分析：pt-kill
* 慢查询分析：Percona Toolkit
* 压力测试：sysbench
* 可视化监控：Prometheus + Grafana

性能优化 - 日常 DB 操作优化项

深夜的告警短信、缓慢滚动的日志、监控面板上刺眼的红色曲线——这些场景背后，往往是未被察觉的效率黑洞。
我们总在架构层面讨论分布式、缓存、分库分表，却忽略了日常编码中那些微小却高频的损耗点。
本文从实战出发，揭秘5个可立即落地的优化技巧，让你从第一行代码开始构建高性能应用。

今日分享几个优化点，很具有代表性，从技术维度上来看，并行化和异步属于并发模型，锁粒度是线程安全核心，集合分配涉及内存管理，启动预处理则是生命周期优化。它们共同构成了高性能系统的骨架。

## 并行化：释放多核处理器的洪荒之力

### 代码实现与优化

日常开发中，我们的代码是否都如以下的实现

```
java

// 顺序处理耗时任务 
for (Item item : itemList) {
    process(item); // 单线程阻塞执行
}
```

并行优化的实现

```
java

// 利用并行流拆分任务（适用于无状态操作）
itemList.parallelStream().forEach(this::process);

// 或使用CompletableFuture实现精细控制
List<CompletableFuture<Void>> futures = itemList.stream()
    .map(item -> CompletableFuture.runAsync(() -> process(item), executor))
    .collect(Collectors.toList());
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
```

### 关键原则

任务独立性：并行任务间避免共享状态

线程池隔离：CPU密集型 vs IO密集型任务使用不同线程池

代价平衡：避免细粒度任务带来的线程调度开销

## 异步处理：别让用户为后台操作买单

### 代码实现与优化

日常开发中的同步阻塞的实现

```
java

public Response handleRequest(Request req) {
    saveLog(req);  // 同步写日志阻塞主线程
    sendMQ(req);   // 同步消息发送
    return doBusinessLogic(req); 
}
```

通过异步解耦方案进行优化

```
java

@Async("ioThreadPool") // Spring异步注解
public void asyncSaveLog(Request req) { ... }

public Response handleRequest(Request req) {
    asyncSaveLog(req);  // 异步日志
    mqTemplate.asyncSend(req); // 消息队列异步发送
    return doBusinessLogic(req); // 主线程快速返回
}
```

### 实现方案

异步解耦的方案各种各样，例如

* Spring @Async + 自定义线程池
* MQ解耦（RabbitMQ/Kafka）
* Reactor响应式编程

我们选择适合当前业务场景的即可

## 锁粒度控制：并发场景的精细手术刀

### 代码实现与优化

1、使用 synchronized 互斥锁

```
java

@RequestMapping("/doSave")
public  synchronized void doSave(String path,String filterUrl){
    // 创建文件夹
    mkdir();
    // 上传文件
    uploadFile(filterUrl);
    // 发送消息
    sendMessage(filterUrl);

}
```

减少锁粒度

```
java

@RequestMapping("/doSave")
public  void doSave(String path,String filterUrl){
    // 创建文件夹
    synchronized (this){
        if(!existPath(path)){
            mkdir();
        }
    }
    // 上传文件
    uploadFile(filterUrl);
    // 发送消息
    sendMessage(filterUrl);

}
```

2、由于我们一般都是多台机器所以我们需要分布式锁

```
java

@RequestMapping("/doSave")
public  void doSave(String path,String filterUrl) {
    String lockKey = "mkdir-lock";
    RLock lock = redissonClient.getLock(lockKey);
    if(lock.tryLock()) {
        try {
            //创建文件夹
            mkdir();
            // 上传文件
            uploadFile(filterUrl);
            // 发送消息
            sendMessage(filterUrl);

        } finally {
            lock.unlock();
        }
    }
}
```

减少锁粒度

```
java

@RequestMapping("/doSave")
public  void doSave(String path,String filterUrl) {
    String lockKey = "mkdir-lock";
    RLock lock = redissonClient.getLock(lockKey);
    if(lock.tryLock()) {
        try {
            //创建文件夹
            mkdir();
        } finally {
            lock.unlock();
        }
    }else{
        return;
    }
    // 上传文件
    uploadFile(filterUrl);
    // 发送消息
    sendMessage(filterUrl);
}
```

3、粗粒度锁的性能瓶颈

```
java

public class CachePool {
    private final Map<String, Object> cache = new HashMap<>();
    private final ReentrantLock lock = new ReentrantLock(); // 全局锁
    
    public void update(String key, Object value) {
        lock.lock(); // 更新任何key都阻塞所有读写
        try { cache.put(key, value); } 
        finally { lock.unlock(); }
    }
}
```

细粒度锁优化

```
java

public class CachePool {
    private final Map<String, Object> cache = new ConcurrentHashMap<>();
    // 使用分段锁（JDK8+推荐直接用ConcurrentHashMap）
    private final Striped<Lock> keyLocks = Striped.lock(32); // Guava分段锁
    
    public void update(String key, Object value) {
        Lock keyLock = keyLocks.get(key);
        keyLock.lock(); // 只锁定当前key的槽位
        try { cache.put(key, value); } 
        finally { keyLock.unlock(); }
    }
}
```

![deepseek_mermaid_20250616_bdf8a9.png](https://blog.liushigong.cn/static/img/da83195aca9b8d35f1bdad388ab1960e.deepseek_mermaid_20250616_bdf8a9.webp)

## 集合空间分配：向动态扩容说“不”

### 代码实现与优化

如何创建一个集合，这还不简单，很快我们就写出下面代码

`List<String> lists = Lists.newArrayList();`

如果说，要往里面插入 1000000 个元素，有没有更好的方式？

```
java

public class ArrayListTest {
    public static void main(String[] args) {
        List<String> userNames = new ArrayList<>();
        Long beginTime = System.currentTimeMillis();
        for(int i = 0;i < 1000000;i++){
            userNames.add("天涯" + i);
        }
        long endTime = System.currentTimeMillis();
        System.out.println("1000000 次插入List花费的时间：" + (endTime - beginTime));

        List<String> userNames2 = new ArrayList<>(1000000);
        Long beginTime2 = System.currentTimeMillis();
        for(int i = 0;i < 1000000;i++){
            userNames2.add("天涯" + i);
        }
        long endTime2 = System.currentTimeMillis();
        System.out.println("1000000 次插入List花费的时间：" + (endTime2 - beginTime2));
    }
}
```

ArrayList 初始大小是 10，超过阈值会按 1.5 倍大小扩容，涉及老集合到新集合的数据拷贝，浪费性能。了解其底层，可以知道 **频繁扩容** 才是罪魁祸首，通过一下测试数据可以看出性能差距

![image.png](https://blog.liushigong.cn/static/img/ed1d8bbc03ada323b2631b8195417046.image.webp)

### 预分配空间优化

如果我们预先知道集合要存储多少元素，初始化集合时尽量指定大小，尤其是容量较大的集合。

```
java

// ArrayList预分配
List<User> userList = new ArrayList<>(100_000); 

// HashMap避免哈希冲突
Map<String, User> userMap = new HashMap<>(100_000, 0.75f); 

// Guava集合工厂
Set<String> typeSet = Sets.newHashSetWithExpectedSize(50);
```

## 项目启动预处理：赢在起跑线上

有很多业务的计算逻辑比较复杂，比如页面要展示一个网站的 PV，教育网站中用户学习时间等等，

如果在用户访问接口的瞬间触发计算逻辑，而这些逻辑计算的耗时通常比较长，很难满足用户的实时性要求。

一般我们都是提前计算，然后将算好的数据预热到缓存中，接口访问时，只需要读缓存即可

如果业务实时性没有那么高，可以通过定时，晚上进行处理计算处理。

还有一种是项目启动时初始化的动作，例如加载字典到缓存中，可以通过实现 `CommandLineRunner` 或 `ApplicationRunner` 接口

### 预热方案实践

```
java

@Component
public class PreloadRunner implements CommandLineRunner {

    @Autowired
    private CacheService cacheService;
    
    @Autowired
    private DbConnectionPool pool;
    
    @Override
    public void run(String... args) {
        // 1. 提前初始化连接池
        pool.warmUp(10); 
        
        // 2. 热点数据缓存预热
        cacheService.preloadHotData();
        
        // 3. 类加载触发（如日志配置）
        LoggerFactory.getLogger(this.getClass());
    }
}
```

性能优化 - 日常开发中的优化项

作为开发者，你是否曾陷入这样的困境: 在流量洪峰来临的瞬间，亲眼目睹服务雪崩？当每秒请求量突破系统临界点时，再强悍的服务器都会变成脆弱的瓷器。而 **限流** 技术，正是守护系统的最后一道智能保险丝——它不会让服务更快，但能确保你在流量海啸中活着上岸。

## 限流

限流就是对请求或并发数进行限制，通过对一定时间内的请求量进行限制来保障系统的正常运行

* 阈值：在一个单位时间内允许的请求量。如 QPS 限制为10，说明 1 秒内最多接受 10 次请求。
* 拒绝策略：超过阈值的请求的拒绝策略，常见的拒绝策略有直接拒绝、排队等待等。

## 限流算法

### 窗口算法

#### 固定窗口算法

固定窗口算法又叫计数器算法，是一种简单方便的限流算法

##### 实现原理

主要通过一个支持原子操作的计数器来累计 1 秒内的请求次数，当 1 秒内计数达到限流阈值时触发拒绝策略，每过 1 秒，计数器重置为 0 开始重新计数

![image.png](https://blog.liushigong.cn/static/img/e80e1a2b02450014d70ceab0b7c93708.image.webp)

##### 实现方式

首先维护一个计数器，将单位时间段当做一个窗口，计数器记录这个窗口接收请求的次数。

当次数少于限流阀值，就允许访问，并且计数器+1，当次数大于限流阀值，就拒绝访问。

当前的时间窗口过去之后，计数器清零。

##### 存在的问题

**一段时间内（不超过时间窗口）系统服务不可用**

比如窗口大小为1s，限流大小为100，然后恰好在某个窗口的第1ms来了100个请求，然后第2ms-999ms的请求就都会被拒绝，这段时间用户会感觉系统服务不可用。

**窗口切换时可能会产生两倍于阈值流量的请求**

假设限流阀值为5个请求，单位时间窗口是1s,如果我们在单位时间内的前0.8-1s和1-1.2s，分别并发5个请求。虽然都没有超过阀值，但是如果算0.8-1.2s,则并发数高达10，已经超过单位时间1s不超过5阀值的定义啦，通过的请求达到了阈值的两倍。

### 滑动窗口算法

滑动窗口限流解决固定窗口临界值的问题，可以保证在任意时间窗口内都不会超过阈值

相对于固定窗口，滑动窗口除了需要引入计数器之外还需要记录时间窗口内每个请求到达的时间点，因此对内存的占用会比较多

#### 实现原理

记录每次请求的时间，统计每次请求的时间 至 往前推1秒这个时间窗口内请求数，并且 1 秒前的数据可以删除。

统计的请求数小于阈值就记录这个请求的时间，并允许通过，反之拒绝。

![image.png](https://blog.liushigong.cn/static/img/dc240252876c9fc60c1751e0c553e4f8.image.webp)

#### 实现方式

它将时间窗⼝划分为更⼩的时间⽚段，每过⼀个时间⽚段，时间窗⼝就会往右滑动⼀格，每个时间⽚段都有独⽴的计数器。

我们在计算整个时间窗⼝内的请求总数时会累加所有的时间⽚段内的计数器。

时间窗⼝划分的越细，那么滑动窗⼝的滚动就越平滑，限流的统计就会越精确

#### 本质

滑动窗口算法其实就是对请求数进行了更细粒度的限流，窗口划分的越多，则限流越精准。

注意

**滑动窗口 和 固定窗口都无法解决短时间之内集中流量的突击**

## 桶算法

### 漏桶算法

原理很简单，可以认为就是注水漏水的过程，往漏桶中以任意速率流入水，以固定的速率流出水。当水超过桶的容量时，会被溢出，也就是被丢弃。因为桶容量是不变的，保证了整体的速率。

#### 实现方式

流入的水滴，可以看作是访问系统的请求，这个流入速率是不确定的。

桶的容量一般表示系统所能处理的请求数，如果桶的容量满了，就达到限流的阀值，就会丢弃水滴（拒绝请求）。流出的水滴，是恒定过滤的，对应服务按照固定的速率处理请求。

![image.png](https://blog.liushigong.cn/static/img/cbb9e91532b8c0330df4df4c17ea7f71.image.webp)

和消息队列思想有点像，削峰填谷

#### 缺点

面对突发请求，服务的处理速度和平时是一样的，这其实不是我们想要的，在面对突发流量我们希望在系统平稳的同时，提升用户体验即能更快的处理请求，而不是和正常流量一样，循规蹈矩的处理（看看，之前滑动窗口说流量不够平滑，现在太平滑了又不行，难搞啊）。

### 令牌桶算法

令牌桶算法是对漏斗算法的一种改进，除了能够起到限流的作用外，还允许一定程度的流量突发。

#### 原理

有一个令牌管理员，根据限流大小，定速往令牌桶里放令牌。如果令牌数量满了，超过令牌桶容量的限制，那就丢弃。

系统在接受到一个用户请求时，都会先去令牌桶要一个令牌。如果拿到令牌，那么就处理这个请求的业务逻辑，如果拿不到令牌，就直接拒绝这个请求。

![image.png](https://blog.liushigong.cn/static/img/8a732a59d36f4ccbf750aef3e591470a.image.webp)

#### 实现

Guava包中提供了令牌桶算法。

可以看出令牌桶在应对突发流量的时候，桶内假如有 100 个令牌，那么这 100 个令牌可以马上被取走，而不像漏桶那样匀速的消费。所以在应对突发流量的时候令牌桶表现的更佳。

### 滑动日志算法

#### 实现原理

记录下所有的请求时间点

新请求到来时先判断最近指定时间范围内的请求数量是否超过指定阈值，由此来确定是否达到限流

#### 实现

可以通过 Redis 的 Zset 实现。

这种方式没有了时间窗口突变的问题，限流比较准确，但是因为要记录下每次请求的时间点，所以占用的内存较多。

## 限流的难点

可以看到每个限流都有个阈值，这个阈值如何定是个难点，定大了服务器可能顶不住，定小了就“误杀”了，没有资源利用最大化，对用户体验不好

我能想到的就是限流上线之后先预估个大概的阈值，然后不执行真正的限流操作，而是采取日志记录方式，对日志进行分析查看限流的效果，然后调整阈值，推算出集群总的处理能力，和每台机子的处理能力(方便扩缩容)

然后将线上的流量进行重放，测试真正的限流效果，最终阈值确定，然后上线

## 限流结论

**固定窗口算法** 实现简单，性能高，但是会有临界突发流量问题，瞬时流量最大可以达到阈值的2倍

为了解决临界突发流量，可以将窗口划分为多个更细粒度的单元，每次窗口向右移动一个单元，于是便有了 **滑动窗口算法**

滑动窗口当流量到达阈值时会瞬间掐断流量，所以导致流量不够平滑，想要达到限流的目的，又不会掐断流量，使得流量更加平滑？可以考虑 **漏桶算法**！需要注意的是，漏桶算法通常配置一个FIFO的队列使用以达到允许限流的作用

由于速率固定，即使在某个时刻下游处理能力过剩，也不能得到很好的利用，这是漏桶算法的一个短板

限流和瞬时流量其实并不矛盾，在大多数场景中，短时间突发流量系统是完全可以接受的，**令牌桶算法** 就是不二之选了，令牌桶以固定的速率v产生令牌放入一个固定容量为n的桶中，当请求到达时尝试从桶中获取令牌，当桶满时，允许最大瞬时流量为n；当桶中没有剩余流量时则限流速率最低，为令牌生成的速率v

如何实现更加灵活的多级限流呢？滑动日志限流算法了解一下！这里的日志则是请求的时间戳，通过计算制定时间段内请求总数来实现灵活的限流。当然，由于需要存储时间戳信息，其占用的存储空间要比其他限流算法要大得多。

如何选择合适的限流算法呢？不妨从 **性能，是否允许超出阈值，落地成本，流量平滑度，是否允许突发流量以及系统资源大小限制** 等多方面考虑

## 限流工具和框架

* Google出品的Guava中基于令牌桶实现的限流组件，拿来即用，不过它毕竟是单机的，可以通过在分布式网关中进行负载均衡，拆分阈值到不同单机上，每台进行汇总即为总阈值
* 面向分布式服务架构的流量控制框架Sentinel更会让你爱不释手，它是基于滑动窗口实现的
* 开源工具如 redisson，已经封装了基于 Redis 的限流