登录
首页 >  文章 >  java教程

线程上下文切换的性能损耗有哪些

时间:2026-01-28 12:54:42 321浏览 收藏

文章小白一枚,正在不断学习积累知识,现将学习到的知识记录一下,也是将我的所得分享给大家!而今天这篇文章《线程上下文切换的性能开销有哪些》带大家来了解一下##content_title##,希望对大家的知识积累有所帮助,从而弥补自己的不足,助力实战开发!


线程上下文切换拖慢Java程序是因为它消耗CPU时间保存/恢复线程状态且不执行业务逻辑,高并发下每秒数万次切换会显著降低性能。

在Java里线程上下文切换带来哪些开销_Java并发性能说明

线程上下文切换为什么会拖慢Java程序

线程上下文切换不是免费的——它让CPU暂时停下当前线程的执行,保存寄存器、栈指针、程序计数器等状态,再加载另一个线程的对应状态。这个过程本身不执行业务逻辑,纯属系统开销。在高并发场景下(比如每秒创建/销毁数百个线程,或频繁争抢锁),上下文切换次数可能飙升到每秒数万次,直接吃掉大量CPU时间。

常见诱因包括:

  • synchronized 块或 ReentrantLock.lock() 争抢失败时触发线程挂起/唤醒
  • 调用 Object.wait()Thread.sleep()LockSupport.park() 等主动让出CPU的操作
  • 线程数远超可用CPU核心数(例如32核机器启了200个活跃线程)
  • 频繁的IO阻塞(如未用NIO的Socket读写)导致线程反复进出RUNNABLE ↔ BLOCKED/WAITING状态

如何观测Java进程里的上下文切换频次

不能只看代码有没有synchronized,得用工具确认实际开销。Linux下最直接的是pidstat -wvmstat

pidstat -w -p <java_pid> 1

重点关注cswch/s(自愿上下文切换)和ncswch/s(非自愿上下文切换)。前者多说明线程主动让渡(如锁竞争、wait);后者高则往往意味着CPU过载或调度延迟。

Java层辅助定位:

  • JDK自带jstack 看线程堆栈,批量出现WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject是典型锁争用信号
  • JFR(Java Flight Recorder)开启jdk.ThreadAllocationjdk.JavaMonitorEnter事件,可关联锁进入耗时与线程状态变更
  • Arthas的thread -n 5快速列出CPU占用最高的5个线程,再结合thread 查其状态

减少上下文切换的实际手段有哪些

不是所有“优化”都有效,得看瓶颈在哪。以下做法经压测验证有明显收益:

  • 用线程池复用线程,避免频繁new Thread().start()——每次新建线程至少触发2次上下文切换(创建+首次调度)
  • synchronized细粒度化,或改用StampedLock(读多写少场景)或LongAdder(计数类)替代AtomicLong,降低CAS失败重试带来的park/unpark
  • 异步化阻塞IO:用CompletableFuture.supplyAsync()包装DB查询,但注意自定义线程池大小,别用ForkJoinPool.commonPool()挤占并行流资源
  • 慎用ThreadLocal:每个ThreadLocal实例会在每个线程的Thread.threadLocals哈希表中存一个Entry,线程生命周期长且ThreadLocal多时,GC压力和内存泄漏风险会上升,间接影响调度效率

为什么用虚拟线程(Project Loom)能大幅缓解这问题

虚拟线程不是“更快的线程”,而是把线程调度从OS级下沉到JVM级。当一个虚拟线程执行Thread.sleep()或阻塞IO时,JVM自动将其挂起,并立即调度同OS线程上的另一个虚拟线程,全程不触发OS上下文切换。

关键事实:

  • 启动10万个虚拟线程只消耗约10MB堆外内存,而10万个平台线程会直接OOM或卡死系统
  • 虚拟线程默认绑定到CarrierThread(后台的平台线程池),数量通常等于CPU核心数,避免OS调度器过载
  • 迁移成本低:只需把new Thread(Runnable)换成Thread.ofVirtual().start(Runnable),原有同步代码逻辑不变
  • 但注意:虚拟线程不解决CPU密集型任务的并行问题,纯计算场景仍需平台线程+并行流

真正容易被忽略的是:虚拟线程对锁的竞争依然存在。如果10万个虚拟线程同时synchronized同一对象,虽然不会压垮OS调度器,但JVM内部的Monitor竞争队列仍会引发大量park/unpark——这时候该换无锁结构,而不是盲目堆虚拟线程数。

终于介绍完啦!小伙伴们,这篇关于《线程上下文切换的性能损耗有哪些》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识,快来关注吧!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>