面对io密集型的(主要是操作数据库)场景，如何设置线程池的各个参数-监控线程-线上排错

@Transactional(propagation = Propagation.REQUIRES_NEW) 的使用：
- 资源消耗：REQUIRES_NEW 传播行为会为该方法开启一个新的事务，这意味着即使当前已经存在一个事务，也会挂起当前事务，创建一个全新的事务。如果在高并发场景下频繁调用此方法，会导致大量的事务创建和销毁，增加数据库和系统的资源消耗。
- 事务一致性问题：新事务与外部事务相互独立，可能会导致数据一致性问题。例如，外部事务回滚时，此方法中的事务不会受到影响，可能会造成数据不一致。
事务管理：根据业务需求，合理选择事务传播行为，确保数据的一致性。如果需要在事务中运行，考虑使用 Propagation.REQUIRED 或其他合适的传播行为。
Spring JDBC 异常：org.springframework.jdbc.CannotGetJdbcConnectionException 是 Spring 框架封装的异常，说明应用程序无法获取到 JDBC 连接。
Druid 连接池异常：com.alibaba.druid.pool.GetConnectionTimeoutException 是 Druid 连接池抛出的获取连接超时异常，进一步说明了问题的根源在于连接池。
- 等待时间：wait millis 10000 表示应用程序等待获取连接的时间达到了 10000 毫秒（即 10 秒），之后判定为超时。
- 活跃连接数：active 20 说明当前连接池中正在被使用的活跃连接数量为 20。
- 最大连接数：maxActive 20 表明连接池配置的最大活跃连接数为 20。
- 正在创建的连接数：creating 0 意味着当前没有新的连接正在创建。
可能的原因分析

连接池方面
- 连接耗尽：从日志可知，当前活跃连接数已达到最大连接数（active 20 且 maxActive 20），说明连接池中的连接已被全部占用。可能是由于应用程序的并发请求过多，超出了连接池的承载能力，新的请求无法获取到空闲连接，从而导致超时。
- 连接未释放：代码中可能存在连接使用后没有正确关闭的情况，导致连接一直被占用，无法归还到连接池中供其他请求使用。随着时间推移，连接池中的连接逐渐被耗尽。
数据库方面
- 数据库负载过高：数据库服务器可能由于大量的并发查询、复杂的业务逻辑或者硬件资源不足等原因，导致处理请求的速度变慢，甚至无法及时响应新的连接请求。
- 数据库故障：数据库服务可能出现了故障，如进程崩溃、磁盘空间不足、内存不足等，影响了其正常运行，使得应用程序无法建立新的连接。
网络方面
- 网络不稳定：应用程序与数据库服务器之间的网络连接可能存在丢包、延迟等问题，导致连接建立失败或者连接超时。
- 防火墙限制：防火墙可能阻止了应用程序与数据库之间的通信，使得连接请求无法正常到达数据库服务器。
解决方案建议

连接池优化
- 调整连接池参数：适当增加连接池的最大连接数（maxActive），以应对更高的并发请求。同时，可以调整连接超时时间（maxWait），避免因等待时间过短而频繁出现超时异常。例如：

import com.alibaba.druid.pool.DruidDataSource;
import javax.sql.DataSource;

public class DataSourceConfig {
    public static DataSource getDataSource() {
        DruidDataSource dataSource = new DruidDataSource();
        dataSource.setUrl("jdbc:mysql://localhost:3306/your_database");
        dataSource.setUsername("your_username");
        dataSource.setPassword("your_password");
        dataSource.setMaxActive(50); // 增加最大连接数
        dataSource.setMaxWait(20000); // 增加连接超时时间
        return dataSource;
    }
}
 

检查连接释放情况：仔细检查代码中使用数据库连接的部分，确保在使用完连接后及时关闭。可以使用 try-with-resources 语句来自动管理资源，避免手动关闭连接时可能出现的遗漏。例如：

try (Connection connection = dataSource.getConnection();
     PreparedStatement statement = connection.prepareStatement("SELECT * FROM your_table")) {
    // 执行查询操作
} catch (SQLException e) {
    e.printStackTrace();
}

在java中，面对io密集型的(主要是操作数据库)场景，如何设置线程池的各个参数?给出经验公式和详细说明。

用户问的是在 Java 中处理 IO 密集型（主要是数据库操作）场景时，如何设置线程池的参数，包括经验公式和详细说明。首先，我需要回忆一下线程池的基本参数，比如核心线程数、最大线程数、队列大小、存活时间等。IO 密集型任务的特点是等待 IO 的时间较长，线程在等待时可以处理其他任务，所以通常需要更多的线程来利用等待时间。

首先，核心线程数的计算。经验公式方面，通常对于 IO 密集型，核心线程数可以设置为 CPU 核心数乘以一个系数，这个系数考虑到等待 IO 的时间。比如，假设 CPU 核心数是 N，每个线程等待 IO 的时间占总时间的比例是 w，那么公式可能是 N * (1 + w/(1-w))。不过更常见的说法是核心线程数可以设置为 CPU 核心数的 2-3 倍，或者使用 N*(1 + 平均等待时间 / 平均工作时间)。这里可能需要明确公式中的参数含义。

然后是最大线程数，对于 IO 密集型，最大线程数可能不需要设置得比核心线程数大很多，因为大部分时间线程在等待 IO，核心线程可能已经足够，但如果有突发流量，可能需要适当调整。队列大小方面，通常使用有界队列，比如 LinkedBlockingQueue，大小根据系统负载和任务处理速度来定，避免内存溢出。存活时间通常设置为 0，如果是使用 FixedThreadPool 的话，不过如果是 CachedThreadPool，存活时间默认是 60 秒，但 IO 密集型可能更适合固定大小的线程池。

另外，需要考虑数据库连接池的配置，线程池的线程数不能超过数据库连接池的最大连接数，否则会导致连接不足，出现阻塞。还要注意线程池的类型，比如使用 ThreadPoolExecutor，自定义参数，而不是使用 Executors 工厂方法，因为后者可能有默认的无界队列，导致 OOM。

需要详细说明每个参数的意义，比如 corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。特别是工作队列的选择，IO 密集型可能适合使用有界队列，避免内存问题。拒绝策略通常使用 AbortPolicy 或者自定义策略，根据业务需求处理拒绝的任务。

还要提到调优的过程，比如通过监控工具观察线程池的运行状态，任务队列的长度，线程的等待时间，调整参数直到达到最佳性能。同时，结合具体场景，比如数据库操作的并发数限制，网络延迟等因素，可能需要调整经验公式中的系数。

总结下来，步骤应该是：确定 CPU 核心数，应用 IO 密集型的经验公式计算核心线程数，设置最大线程数（可能等于或稍大于核心数），选择合适的队列类型和大小，设置存活时间，考虑数据库连接池的限制，选择合适的拒绝策略，并强调监控和调优的重要性。

在 Java 中处理 IO 密集型（尤其是数据库操作）场景时，线程池参数的合理设置对性能至关重要。以下是基于经验公式和最佳实践的详细说明：

一、核心参数与经验公式

1. 核心线程数（`corePoolSize`）

公式：

corePoolSize = N_{CPU} \times (1 + 平均计算时间 平均 IO 等待时间)

$N_{CPU}$ ：CPU 核心数（可通过Runtime.getRuntime().availableProcessors()获取）。
物理意义：IO 密集型任务中，线程大部分时间在等待 IO（如数据库查询、网络请求），计算时间占比低。通过公式放大核心线程数，利用等待时间处理其他任务。

经验取值：

若无法精确计算 IO 与计算时间比例，通常设置为 CPU 核心数的 2~3 倍（例如 4 核 CPU 设为 8~12）。
若数据库操作以短连接为主（如高频小查询），可适当增加核心数（3~5 倍）；若长连接或大吞吐量操作（如批量写入），需结合数据库连接池最大连接数（见下文注意点）。

2. 最大线程数（`maximumPoolSize`）

IO 密集型场景特点：线程等待 IO 时不会占用 CPU，理论上可创建较多线程，但受限于系统资源（如数据库连接数、文件句柄）。
设置原则：
- 通常 等于或略大于corePoolSize（如 1.5~2 倍），避免无意义的线程创建 / 销毁开销。
- 绝对上限：不超过 数据库连接池最大连接数（如 JDBC 连接池maxPoolSize），否则会因连接不足导致阻塞。

3. 任务队列（`workQueue`）

选择有界队列（如ArrayBlockingQueue或LinkedBlockingQueue），避免无界队列（如Executors.newFixedThreadPool默认的Integer.MAX_VALUE）导致 OOM。
队列大小：
- 经验值：核心线程数的 2~5 倍（例如核心数 10，队列大小设为 20~50）。
- 动态调整：根据监控（如队列积压任务数）优化，避免队列过长导致请求延迟。

4. 线程存活时间（`keepAliveTime`）

当线程数 > corePoolSize时，空闲线程的存活时间。
IO 密集型建议：设为 5~30 秒（短存活时间减少资源浪费），或直接设为0（若maximumPoolSize == corePoolSize，即固定大小线程池）。

5. 拒绝策略（`RejectedExecutionHandler`）

默认策略：AbortPolicy（抛出异常），适合快速失败并触发业务降级。
推荐策略：
- CallerRunsPolicy：将任务回退到调用线程执行，避免丢失任务（需确保调用线程非核心业务线程）。
- 自定义策略：记录日志、异步重试或熔断（如结合 Hystrix）。

二、数据库场景特殊注意点

1. 与数据库连接池联动

线程池最大线程数 不得超过数据库连接池最大连接数（如 HikariCP 默认maxPoolSize=10，则线程池maximumPoolSize应≤10）。
若线程数超过连接数，会导致大量线程阻塞在获取数据库连接而非执行SQL，反而降低性能。

2. 批量操作优化

批量写入（如Batch操作）时，核心线程数可适当减小（避免连接竞争），队列大小根据批量任务耗时调整。
使用CompletableFuture或异步 DAO（如 MyBatis-Plus 异步方法）配合线程池，降低同步阻塞。

三、线程池类型选择

避免使用Executors工厂方法（如newFixedThreadPool/newCachedThreadPool），因其默认配置不适合生产环境：

newFixedThreadPool：无界队列（LinkedBlockingQueue）可能导致内存溢出。
newCachedThreadPool：最大线程数Integer.MAX_VALUE，易引发资源耗尽。

推荐自定义ThreadPoolExecutor：

java
 
 
 
 
 

int corePoolSize = Runtime.getRuntime().availableProcessors() * 2; // 假设2倍CPU核心
int maxPoolSize = corePoolSize * 1.5; // 1.5倍核心数
int queueCapacity = corePoolSize * 3; // 队列大小3倍核心数
long keepAliveTime = 30; // 30秒存活时间

ThreadPoolExecutor threadPool = new ThreadPoolExecutor(
    corePoolSize,
    maxPoolSize,
    keepAliveTime,
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(queueCapacity),
    new ThreadFactoryBuilder().setNameFormat("db-io-thread-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);
 

四、监控与调优

关键指标：
- taskCount：已提交任务总数。
- completedTaskCount：已完成任务数。
- queue.size()：队列积压任务数（理想值趋近于 0，持续增长需调大核心数或队列大小）。
- activeCount：当前活跃线程数（是否接近maxPoolSize，判断是否需要扩容）。
工具：
- 内置 API：通过ThreadPoolExecutor的get*()方法获取状态。
- 监控框架：Micrometer（配合 Prometheus/Grafana）、Spring Boot Actuator。
调优方向：
- 若队列长期积压：增加corePoolSize或queueCapacity。
- 若线程数常达maxPoolSize：检查数据库连接池配置，或优化 SQL 减少 IO 等待时间。

五、总结

参数	IO 密集型（数据库场景）建议值	说明
`corePoolSize`	CPU 核心数 × 2~3（或公式计算）	利用 IO 等待时间并行处理任务
`maximumPoolSize`	等于或略大于`corePoolSize`（≤数据库连接池上限）	避免连接竞争和资源耗尽
`workQueue`	有界队列（如`ArrayBlockingQueue`）	队列大小 = 核心数 ×2~5，防止内存溢出
`keepAliveTime`	5~30 秒（或 0，若固定大小线程池）	减少空闲线程资源消耗
`RejectedExecutionHandler`	`CallerRunsPolicy`或自定义策略	避免任务丢失，结合业务逻辑处理拒绝情况

通过合理设置参数并结合监控调优，可在数据库 IO 场景中充分发挥线程池的并发能力，同时避免资源瓶颈。

-如何通过监控框架：Micrometer（配合Prometheus/Grafana）、Spring Boot Actuator。详细监控上述线程池?

已完成思考

用户现在的问题是如何通过 Micrometer 配合 Prometheus 和 Grafana，以及 Spring Boot Actuator 来详细监控之前讨论的 Java 线程池。首先，我需要回忆一下用户之前的问题是关于 IO 密集型场景下线程池参数设置，现在转向监控，所以需要结合 Spring Boot 的相关组件。

首先，Spring Boot Actuator 提供了对应用内部状态的监控端点，而 Micrometer 是一个通用的监控指标收集库，支持多种监控系统，包括 Prometheus。所以步骤应该包括在 Spring Boot 中启用 Actuator，配置 Micrometer 与 Prometheus 的集成，然后收集线程池的指标。

接下来，需要考虑线程池的指标有哪些。比如活跃线程数、最大线程数、队列大小、任务提交数、完成数、拒绝数等。Micrometer 可以通过 MeterRegistry 来注册这些指标。对于 Java 自带的 ThreadPoolExecutor，可以使用 Micrometer 的支持类，比如 ThreadPoolExecutorMetrics，或者手动注册 Gauge、Counter 等指标。

然后，配置 Prometheus 来拉取这些指标，需要设置 Spring Boot 的管理端口和 Prometheus 的端点。之后在 Grafana 中导入 Prometheus 数据源，并创建仪表盘来展示这些指标，可能需要编写 PromQL 查询来获取具体的数据，比如当前活跃线程数、队列中的任务数等。

还要注意用户使用的是 Spring Boot，所以可能需要添加相关的依赖，比如 spring-boot-starter-actuator 和 micrometer-registry-prometheus。另外，线程池可能是在应用中自定义的，需要确保在创建线程池时注册监控指标，或者使用 Spring 的线程池配置，通过 Actuator 自动暴露指标。

可能还需要考虑如何命名指标，添加标签（tag）来区分不同的线程池，方便在 Grafana 中过滤和展示。比如为每个线程池添加名称标签，便于监控多个线程池的情况。

最后，需要详细说明每个步骤，从依赖添加、配置文件设置、指标注册、Prometheus 配置到 Grafana 仪表盘的创建，确保用户能够一步步实施。同时，给出示例代码，比如如何注册线程池指标，配置 application.properties，Prometheus 的配置文件，以及 Grafana 中的查询示例，这样用户可以更直观地理解和操作。

以下是通过 Micrometer + Prometheus + Grafana + Spring Boot Actuator 监控 Java 线程池的详细方案，包含配置步骤、指标采集和可视化展示：

一、核心依赖配置

在 pom.xml 中添加监控相关依赖：

xml
 
 
 
 
 

<!-- Spring Boot Actuator -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Micrometer Prometheus 注册表 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
<!-- 可选：若使用自定义线程池，需手动注册指标 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>
 

二、Spring Boot 配置（`application.properties`）

properties
 
# 启用 Actuator 端点
management.endpoints.web.exposure.include=prometheus,health,info
# 管理端口（默认 8080，若与应用端口冲突可修改）
management.server.port=8081
# Prometheus 端点路径（默认 /actuator/prometheus）
management.endpoint.prometheus.enabled=true
# 指标命名策略（可选，建议保留默认）
micrometer.naming.strategy=snake_case

三、线程池指标采集

1. 自动监控 Spring 管理的线程池（推荐）

若使用 @Configuration 中定义的 ThreadPoolTaskExecutor 或 AsyncTaskExecutor，Spring Boot Actuator 会自动暴露以下指标（以 spring.task.execution.thread-pool 开头）：

active_count：当前活跃线程数
core_pool_size：核心线程数
max_pool_size：最大线程数
pool_size：当前线程池大小
queue_size：任务队列大小（如 LinkedBlockingQueue 的剩余容量）
task_count：累计提交的任务数
completed_task_count：累计完成的任务数

2. 手动监控自定义线程池（非 Spring 管理）

若使用原生 ThreadPoolExecutor，需手动注册指标：

java
 
 
 
 
 

import io.micrometer.core.annotation.Timed;
import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.binder.ThreadPoolExecutorMetrics;
import java.util.concurrent.ThreadPoolExecutor;

public class CustomThreadPool {
    private final ThreadPoolExecutor threadPool;

    public CustomThreadPool(MeterRegistry meterRegistry, String poolName) {
        threadPool = new ThreadPoolExecutor(
            5, 20, 30, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100)
        );
        // 注册线程池指标（名称、标签）
        new ThreadPoolExecutorMetrics(threadPool)
            .bindTo(meterRegistry)
            .withTag("pool", poolName); // 添加标签区分不同线程池
    }
}
 

核心指标（手动 / 自动均适用）：

指标名称	类型	说明
`thread_pool.active_count`	Gauge	当前活跃线程数
`thread_pool.core_pool_size`	Gauge	核心线程数
`thread_pool.max_pool_size`	Gauge	最大线程数
`thread_pool.pool_size`	Gauge	当前线程池大小（已创建的线程数）
`thread_pool.queue_size`	Gauge	任务队列剩余容量（未执行任务数）
`thread_pool.task_count`	Counter	累计提交的任务数
`thread_pool.completed_task_count`	Counter	累计完成的任务数
`thread_pool.rejected_count`	Counter	被拒绝的任务数（需自定义拒绝策略时统计）

四、Prometheus 配置（`prometheus.yml`）

添加 Spring Boot Actuator 端点作为数据源：

yaml
 
scrape_configs:
  - job_name: "spring-boot"
    metrics_path: "/actuator/prometheus" # 对应 Spring Boot 的 Prometheus 端点
    static_configs:
      - targets: ["localhost:8081"] # 管理端口，与 application.properties 一致

五、Grafana 可视化配置

1. 添加 Prometheus 数据源

登录 Grafana（默认端口 3000），进入 Configuration > Data Sources
点击 Add data source，选择 Prometheus
输入 Prometheus 地址（如 http://localhost:9090，根据实际部署调整）

2. 创建线程池监控仪表盘

核心面板示例：

1. 当前活跃线程数 vs 核心 / 最大线程数

promql
 
# 活跃线程数
thread_pool.active_count{pool="dbThreadPool"}  // 替换 pool 标签
# 核心线程数
thread_pool.core_pool_size{pool="dbThreadPool"}
# 最大线程数
thread_pool.max_pool_size{pool="dbThreadPool"}

2. 任务队列积压情况

promql
 
thread_pool.queue_size{pool="dbThreadPool"}  // 队列剩余容量（值越大积压越严重）

3. 任务提交 / 完成速率（每分钟）

promql
 
rate(thread_pool.task_count{pool="dbThreadPool"}[1m])  // 提交速率
rate(thread_pool.completed_task_count{pool="dbThreadPool"}[1m])  // 完成速率

4. 任务拒绝率（需自定义拒绝策略并统计）

若使用 ThreadPoolExecutor.CallerRunsPolicy 以外的策略（如 AbortPolicy），需手动统计拒绝次数：

java
 
 
 
 
 

// 自定义拒绝策略
threadPool.setRejectedExecutionHandler(new RejectedExecutionHandler() {
    private final Counter rejectedCounter = Counter.builder("thread_pool.rejected_count")
        .tag("pool", "dbThreadPool")
        .description("Rejected tasks")
        .register(meterRegistry);

    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        rejectedCounter.increment();
    }
});
 

查询：

promql

rate(thread_pool.rejected_count{pool="dbThreadPool"}[1m])

六、最佳实践

标签区分多线程池：通过 withTag("pool", "poolName") 为不同线程池（如数据库操作、文件 IO）添加标签，避免指标混杂。
阈值报警：在 Grafana 中设置报警规则，例如：
- 当 queue_size > 500 时触发队列积压预警
- 当 active_count > max_pool_size * 0.9 时触发线程池负载过高预警
长期趋势分析：结合 task_count 和 completed_task_count 分析吞吐量瓶颈，辅助调整线程池参数（如核心线程数、队列大小）。

监控延迟指标：若业务对延迟敏感，可额外添加方法级监控（@Timed 注解），追踪任务处理耗时：

 
@Timed(value = "db.query.time", description = "Database query latency", tags = {"pool", "dbThreadPool"})
public void processDatabaseTask() {
    // 数据库操作
}

七、完整流程总结

依赖与配置：通过 Spring Boot Actuator 和 Micrometer 暴露线程池指标到 Prometheus 端点。
指标注册：自动监控 Spring 管理的线程池，或手动绑定原生 ThreadPoolExecutor 到 Micrometer。
Prometheus 抓取：配置 Prometheus 定期拉取 Actuator 端点的指标数据。
Grafana 可视化：通过仪表盘实时展示线程池负载、队列积压、任务速率等关键指标，结合标签实现多池区分。

通过以上方案，可全面监控 IO 密集型场景下线程池的运行状态，及时发现性能瓶颈并优化参数配置。

posted @ 2025-05-08 14:50 CharyGao 阅读(257) 评论(0) 收藏举报

刷新页面返回顶部

硅基文明

代码改变不了世界，但是改变世界需要代码。

面对io密集型的(主要是操作数据库)场景，如何设置线程池的各个参数-监控线程-线上排错

可能的原因分析

连接池方面

数据库方面

网络方面

解决方案建议

连接池优化

一、核心参数与经验公式

1. 核心线程数（`corePoolSize`）

2. 最大线程数（`maximumPoolSize`）

3. 任务队列（`workQueue`）

4. 线程存活时间（`keepAliveTime`）

5. 拒绝策略（`RejectedExecutionHandler`）

二、数据库场景特殊注意点

1. 与数据库连接池联动

2. 批量操作优化

三、线程池类型选择

四、监控与调优

五、总结

一、核心依赖配置

二、Spring Boot 配置（`application.properties`）

三、线程池指标采集

1. 自动监控 Spring 管理的线程池（推荐）

2. 手动监控自定义线程池（非 Spring 管理）

四、Prometheus 配置（`prometheus.yml`）

五、Grafana 可视化配置

1. 添加 Prometheus 数据源

2. 创建线程池监控仪表盘

核心面板示例：

1. 当前活跃线程数 vs 核心 / 最大线程数

2. 任务队列积压情况

3. 任务提交 / 完成速率（每分钟）

4. 任务拒绝率（需自定义拒绝策略并统计）

六、最佳实践

七、完整流程总结

硅基文明

代码改变不了世界，但是改变世界需要代码。

面对io密集型的(主要是操作数据库)场景，如何设置线程池的各个参数-监控线程-线上排错

可能的原因分析

连接池方面

数据库方面

网络方面

解决方案建议

连接池优化

一、核心参数与经验公式

1. 核心线程数（corePoolSize）

2. 最大线程数（maximumPoolSize）

3. 任务队列（workQueue）

4. 线程存活时间（keepAliveTime）

5. 拒绝策略（RejectedExecutionHandler）

二、数据库场景特殊注意点

1. 与数据库连接池联动

2. 批量操作优化

三、线程池类型选择

四、监控与调优

五、总结

一、核心依赖配置

二、Spring Boot 配置（application.properties）

三、线程池指标采集

1. 自动监控 Spring 管理的线程池（推荐）

2. 手动监控自定义线程池（非 Spring 管理）

四、Prometheus 配置（prometheus.yml）

五、Grafana 可视化配置

1. 添加 Prometheus 数据源

2. 创建线程池监控仪表盘

核心面板示例：

1. 当前活跃线程数 vs 核心 / 最大线程数

2. 任务队列积压情况

3. 任务提交 / 完成速率（每分钟）

4. 任务拒绝率（需自定义拒绝策略并统计）

六、最佳实践

七、完整流程总结

1. 核心线程数（`corePoolSize`）

2. 最大线程数（`maximumPoolSize`）

3. 任务队列（`workQueue`）

4. 线程存活时间（`keepAliveTime`）

5. 拒绝策略（`RejectedExecutionHandler`）

二、Spring Boot 配置（`application.properties`）

四、Prometheus 配置（`prometheus.yml`）