一、业务背景
在xx系统中，xx标签匹配模块是支撑多个下游业务的关键数据源。该模块每小时需要定时对 20万+ x 1000+条MVEL规则进行处理，涵盖：
- 标签匹配条件判断
- 动态标签集合处理
任务采用 线程池并发处理 ，最大并发线程数为 60 。随着数据量和规则复杂度的提升，系统在任务期间出现了严重的 CPU过载问题 ，因为服务还对外提供接口服务，存在影响整体服务稳定性的风险，急需要解决。
二、问题定位与技术分析
2.1 问题现象
- CPU峰值使用率高达94.03%
- 任务执行耗时增加30%
- 线程池持续高负载运行
2.2 技术根因分析
1.规则引擎计算密集 ：MVEL表达式在大量嵌套、集合操作场景下对CPU消耗巨大
2.线程池调度无反馈机制 ：任务提交即执行，缺乏系统负载感知
三、CPU监控方案对比
为了实现系统级CPU使用率的精准采集与动态反馈 ，我们需要对系统CPU进行监控并干预，这里对多个监控方案进行了横向对比，最终我们选择 OSHI 作为核心监控组件（https://github.com/oshi/oshi），它具备以下优势：
- 纯Java实现，无需安装本地库
- 支持Linux、Windows、macOS等主流操作系统
- 提供系统级、进程级、线程级的资源采集
- 可与Prometheus、Grafana集成，构建完整监控闭环
四、线程池自适应调度架构设计
4.1 架构目标
我们希望构建一个具备以下能力的线程调度模式：
- 实时感知系统负载
- 动态调整任务执行频率
- 支持热更新配置
- 具备异常容错机制
4.2 架构图
4.3 调控策略设计
我们设计了基于CPU使用率的三档动态sleep策略 ，线程池在执行任务前通过 beforeExecute 钩子感知系统负载，插入不同长度的 Thread.sleep() 实现节流。
| CPU负载等级 | 阈值 | 线程池sleep时间 |
|---|---|---|
| 高负载 | ≥70% | 1000ms |
| 中负载 | ≥60% | 800ms |
| 低负载 | ≥50% | 500ms |
五、关键实现细节
5.1 守护线程与CPU监控
我们构建了一个守护线程CpuUsageMonitor ，持续采集系统CPU使用率，并根据负载动态调整采集频率。
守护线程监控模块
@Component@Slf4jpublicclassCpuUsageMonitor{privatestaticvolatiledoublelatestCpuUsage=0.0;privatestaticfinalObjectLOCK=newObject();privatefinalSystemInfosystemInfo=newSystemInfo();privatevoidstartCpuUsageMonitor(){monitorThread=newThread(()->{log.info("op: cpu.monitor.start, desc: CPU监控线程启动");while(!Thread.currentThread().isInterrupted()){try{doublecurrentUsage=getCpuUsageByOshi();synchronized(LOCK){//cpu使用率latestCpuUsage=currentUsage;}longsleepTime=daemonSleepTimeLow;if(currentUsage>=thresholdHigh){sleepTime=daemoSleepTimeHigh;}elseif(currentUsage>=thresholdMedium){sleepTime=daemoSleepTimeMedium;}elseif(currentUsage>=thresholdLow){sleepTime=daemonSleepTimeLow;}Thread.sleep(sleepTime);}catch(InterruptedExceptione){log.warn("op: cpu.monitor.interrupt, desc: 线程被中断，准备退出");Thread.currentThread().interrupt();break;}}// 循环重启机制if(!Thread.currentThread().isInterrupted()){startCpuUsageMonitor();}});monitorThread.setDaemon(true);monitorThread.setName("CpuUsageMonitorThread");monitorThread.setUncaughtExceptionHandler((t,e)->log.error("op: cpu.usage.fetch, desc: 线程发生未捕获异常: {}",t.getName(),e));monitorThread.start();}publicvoidgetCpuUsageMonitor(){while(true){try{doublecpuUsage=CpuUsageMonitor.getLatestCpuUsage();if(cpuUsage>=thresholdHigh){Thread.sleep(threadSleepTimeHigh);}elseif(cpuUsage>=thresholdMedium){Thread.sleep(threadSleepTimeMedium);}elseif(cpuUsage>=thresholdLow){Thread.sleep(threadSleepTimeLow);}else{break;}}catch(InterruptedExceptione){log.warn("op: cpu.monitor.interrupt, desc: CPU监控线程被中断，准备退出...");Thread.currentThread().interrupt();break;}}}}5.2 线程池增强与beforeExecute钩子
我们通过继承 ThreadPoolExecutor，重写 beforeExecute 方法，使其在任务执行前调用 CpuUsageMonitor 获取当前CPU使用率，并根据阈值插入sleep。
线程池增强实现
publicabstractclassBaseThreadPoolExecutorextendsThreadPoolExecutor{privatefinalCpuUsageMonitorcpuUsageMonitor;protectedBaseThreadPoolExecutor(intcorePoolSize,intmaximumPoolSize,longkeepAliveTime,TimeUnitunit,BlockingQueue<Runnable>workQueue,ThreadFactorythreadFactory,RejectedExecutionHandlerhandler,CpuUsageMonitorcpuUsageMonitor){super(corePoolSize,maximumPoolSize,keepAliveTime,unit,workQueue,threadFactory,handler);this.cpuUsageMonitor=cpuUsageMonitor;}// 线程池开始执行任务前的操作@OverrideprotectedvoidbeforeExecute(Threadt,Runnabler){try{// 获取cpu使用率 并可能睡眠if(cpuUsageMonitor!=null){cpuUsageMonitor.getCpuUsageMonitor();}}catch(Exceptione){log.error("线程池beforeExecute方法执行异常",e);}super.beforeExecute(t,r);}}5.3 Nacos 动态配置中心集成
通过集成 Nacos配置中心 ，我们实现了CPU阈值与节流参数的热更新，无需重启服务即可生效。
参数配置可以结合业务实际的需求来动态调配
cpu:config:# 轻度负载阈值 threshold-low:50.0# 中度负载阈值 threshold-medium:60.0# 高度负载阈值 threshold-high:70.0# 线程轻度超限睡眠时间 thread-sleep-time-low:500# 线程中度超限睡眠时间 thread-sleep-time-medium:800# 线程高度超限睡眠时间 thread-sleep-time-high:1000# 守护线程轻度间隔时间 daemo-sleep-time-low:1000# 守护线程中度间隔睡眠时间 daemo-sleep-time-medium:2000# 守护线程高度间隔睡眠时间 daemo-sleep-time-high:3000六、优化效果与性能对比
优化后定时任务执行时系统CPU比较平稳，稳定在 40%-70% 范围，虽然任务执行时间略有增加，但CPU资源得到了有效控制，系统整体稳定性显著提升，且具备了动态调节能力。
| 指标 | 优化前 | 优化后 | 改善幅度 |
|---|---|---|---|
| CPU峰值使用率 | 94.03% | 63.17% | ↓32.8% |
| CPU波动范围 | 70-95% | 40-70% | 稳定性↑ |
| 任务执行耗时 | 120s | 150s | ±25% |
七、异常处理与容错机制
7.1 守护线程异常捕获与重启
- 设置 UncaughtExceptionHandler，防止异常退出
- 线程中断后自动重启，保证监控不中断
- 日志记录异常信息，便于运维排查
7.2 线程池钩子方法容错
- beforeExecute 中捕获所有异常，避免影响任务执行
- 设置默认节流策略，防止因监控失败导致系统过载
- 提供熔断机制，当监控组件不可用时自动降级为固定节流
八、总结与反思
本次优化通过引入 CPU使用率感知机制 ，结合线程池钩子与动态节流策略，成功将CPU峰值从 90%+ 降至 60%左右 ，任务执行稳定性显著提升。
更重要的是，我们构建了一套 可感知、可配置、可扩展 的资源调度体系，为后续系统级资源治理、弹性调度打下了坚实基础。
本次优化的启示：
- 单纯的“线程池并发”并不能解决资源争用问题
- 系统资源的使用必须有“感知”和“反馈”机制
- 业务模块之间需要有“资源隔离”意识
- 高性能与高稳定性可以共存，关键在于调度的合理性与反馈的智能性
