写点什么

线上机器 CPU 占用高分析实践

  • 2025-02-20
    北京
  • 本文字数:1940 字

    阅读完需:约 6 分钟

1. 线程运行状态

1.1 total





1.2 timed_waiting







通过上图我们可以发现 timed_waiting 的 topN 线程都是查询国补资质的。1.3 waiting







通过上图我们可以发现 waiting 的 topN 线程都是查询国补活动的。

1.3 waiting







通过上图我们可以发现 waiting 的 topN 线程都是查询国补活动的。


1.4 线程分析下面我们分析上述两种状态:


  1. WAITING 状态


•定义:当一个线程处于 WAITING 状态时,它在等待另一个线程的特定操作(如通知或中断),并且不会继续执行。•触发条件:线程进入 WAITING 状态的常见情况包括:调用 Object.wait() 方法:线程在等待某个对象的监视器(锁)被其他线程通知。


调用 Thread.join() 方法:等待另一个线程完成。
调用 LockSupport.park() 方法:线程被阻塞,直到它被其他线程唤醒。
复制代码


•恢复:线程在 WAITING 状态下将一直保持此状态,直到其他线程调用 notify() 或 notifyAll()(对于 Object.wait()),或者被中断。2. TIMED_WAITING 状态


•定义:当一个线程处于 TIMED_WAITING 状态时,它在等待某个条件的发生,但它会在指定的时间后自动返回。•触发条件:线程进入 TIMED_WAITING 状态的常见情况包括:调用 Thread.sleep(milliseconds):线程休眠指定的毫秒数。


调用 Object.wait(milliseconds):线程在等待某个对象的监视器(锁),并且在指定的时间内等待。
调用 Thread.join(milliseconds):等待另一个线程完成,但有时间限制。
调用 LockSupport.parkNanos() 或 LockSupport.parkUntil()。
复制代码

•恢复:线程在 TIMED_WAITING 状态下会在指定的时间结束后自动恢复,或者在其他线程调用 notify() 或 notifyAll() 时恢复。


| 状态           | 描述                                     | 触发条件                                    | 恢复方式                                   ||----------------|------------------------------------------|---------------------------------------------|--------------------------------------------|| **WAITING**    | 线程等待另一个线程的特定操作,不会继续执行 | `Object.wait()`, `Thread.join()`, `LockSupport.park()` | 其他线程调用 `notify()`/`notifyAll()` 或被中断 || **TIMED_WAITING** | 线程等待某个条件的发生,但有时间限制   | `Thread.sleep(milliseconds)`, `Object.wait(milliseconds)`, `Thread.join(milliseconds)` | 超过指定时间后自动恢复,或其他线程调用 `notify()`/`notifyAll()` |
复制代码


上文中 queryActTp 为 getActivityInfo 执行并发任务,其中包含两个子任务、 queryQualityTp 为 getQualityInfo 执行并发任务,其中五个子任务。同时将这俩任务放到 queryActAndQualityTp 中并行。


getActivityInfo 所在的秒级监控如下:

下面我们结合实际代码情况分析:





上文中 queryActTp 为 getActivityInfo 执行并发任务,其中包含两个子任务、 queryQualityTp 为 getQualityInfo 执行并发任务,其中五个子任务。同时将这俩任务放到 queryActAndQualityTp 中并行。

getActivityInfo 所在的秒级监控如下:





getQualityInfo 所在的秒级监控如下;





上文中同样的调用方式,但是出现了两种线程状态,理论上应该都是TIMED_WAITING。针对queryActTp 我们可以发现堆栈信息中也是 LockSupport.park 而不是 LockSupport.parkNanos。具体原因有待进一步分析。

上述代码中还有一个问题就是 A 线程池中又并行调用了 B、C 线程池,在大流量情况下,CPU 频繁切换也会造成一定的 CPU 压力,我们改写这块逻辑用一个线程池实现活动和资质的并发查询。鉴于改动较大,本次先不动。

2. 火焰图分析





2.1 wait 线程





2.2 锁性能





2.3 CPU 采样





2.3.1 getFatherActivity 分析





Q1:调用场景:循环中调用 getFatherActivity

Q2:查看配置数据,json 格式化后 50000 字符,大对象的反序列化

Q3:使用 new ArrayList() 创建新对象

Q4:分组后只用了对象中的第一个元素,这里用 toMap 更佳

优化 1:





我们可以发现上文在循环中还是会存在多次的 stream 调用,继而将 toMap 逻辑提到循环外,如下:





其他方法确实占用 CPU 较高,这里先不处理。

下文再优化一项获取并发线程执行结果的工具类:





1、 allOf异常后,取消所有线程的继续执行。这么做为了防止有些线程超时后仍在执行,浪费部分CPU资源,线上发现确实存在较多的超时情况。2、 这里的异常日志较多,根据异常类型进行区分,去掉没用的堆栈日志。
复制代码

并发线程中所有的等待统一都使用了上文的方法,前文中的 queryActTp 处于 WAITING 状态可能也是执行没取消导致,修改部署后再观察分析。同样的调用方式 queryQualityTp 处于 Timed_waiting 状态可能与一次父任务中子任务的执行耗时有关,见上文监控,活动和资质相差较大,具体原因有待进一步分析。

发布于: 刚刚阅读数: 5
用户头像

还未添加个人签名 2024-01-12 加入

京东零售那些事,有品、有调又有料的研发资讯,带你深入了解程序猿的生活和工作。

评论

发布
暂无评论
线上机器CPU占用高分析实践_京东零售技术_InfoQ写作社区