什么时候用单线程什么时候用多线程图里展示了一个典型的网络请求场景左侧处理耗时1ms网络请求往返耗时25ms 25ms 50ms右侧处理耗时2ms整个流程总耗时1ms 25ms 2ms 25ms 53ms这里的瓶颈明显是网络 IO 等待50ms而不是 CPU 计算总共只占 3ms图里还提到了一个对比场景for() 1-1亿 --- 单线程这是纯 CPU 计算密集型任务什么时候用多线程对应图里的 IO 密集场景✅IO 密集型任务优先用多线程图里的文字也直接点明了io,访问网络,访问硬盘---IO密集--多线程合适适用场景网络请求API 调用、数据库查询、文件下载磁盘读写文件读写、数据库操作其他阻塞式等待如用户输入、队列等待为什么这类任务的大部分时间线程都在 “等待”等网络响应、等磁盘读写完成CPU 是空闲的。用多线程可以在等待的间隙让 CPU 去处理其他任务把等待时间 “利用起来”大幅提升整体效率。比如图里的场景如果同时发起多个请求就能重叠等待时间总耗时会从 53ms 降到接近 52ms1252效率翻倍。什么时候用单线程对应图里的 CPU 密集场景✅CPU 密集型任务优先用单线程或少量线程图里的for() 1-1亿就是典型例子纯计算、无等待全程都在占用 CPU。适用场景大规模数值计算、复杂算法运算视频 / 图片编码解码循环遍历、数据批量处理无 IO 操作为什么这类任务全程都在占用 CPU多线程会带来额外的线程切换开销反而降低效率多线程还会引发 CPU 缓存失效、资源竞争等问题进一步拖慢速度对于 Python 这类有 GIL全局解释器锁的语言多线程甚至无法真正并行执行 CPU 密集任务反而不如单线程高效一句话总结IO 密集型等待多、计算少用多线程让等待时间 “物尽其用”CPU 密集型计算多、等待少用单线程避免线程切换开销保证效率jion()函数的作用t1.join();作用让当前线程比如主线程等待t1线程执行完成再继续往下走。也就是说join()会阻塞当前线程直到t1线程死亡执行完毕后面的代码才会开始执行。1. 测量上下文切换的时长Lmbench3命令vmstat 1减少上下文切换1. 无锁并发编程原理多线程竞争锁时会触发阻塞 / 唤醒引发大量上下文切换。无锁编程通过避免锁竞争减少这类开销。实现思路数据分段按 ID 哈希取模让不同线程处理不同分段的数据从根源上避免共享资源竞争。典型场景分库分表、数据分片处理。2. CAS 算法原理Compare-And-Swap比较并交换是一种乐观锁机制通过硬件指令实现原子更新无需加锁。应用示例Java 中的java.util.concurrent.atomic包如AtomicInteger底层基于 CAS 实现线程安全避免了传统锁带来的阻塞和上下文切换。3. 使用最少线程原理线程过多会导致 CPU 调度频繁大量线程处于等待 / 就绪状态加剧上下文切换。优化方式线程数与 CPU 核心数匹配CPU 密集型任务核心数 1IO 密集型可适当增加但避免过度创建。避免 “任务少、线程多” 的场景减少不必要的线程创建。4. 使用协程原理协程是用户态的轻量级线程在单线程内实现多任务调度切换由用户程序控制无需内核参与。优势协程切换不涉及内核态 / 用户态切换开销极低大幅减少上下文切换次数。典型场景高并发 IO 场景如网络请求、异步处理通过协程实现高效的任务调度。目标通过减少大量处于WAITING状态的空闲线程降低系统上下文切换次数优化性能。减少上下文切换实战第一步获取线程快照jstack命令工具jstackJDK 自带的 Java 线程分析工具命令示例sudo -u admin /opt/ifeve/java/bin/jstack 31177 /home/tengfei.fangtf/dump17作用导出进程 ID 为31177的 Java 进程的所有线程快照保存为dump17文件。目的查看进程内所有线程的运行状态定位性能瓶颈。第二步统计线程状态分布命令示例grep java.lang.Thread.State dump17 | awk {print $2$3$4$5} | sort | uniq -c作用从线程快照中提取所有线程状态统计每种状态的线程数量。统计结果解读状态线程数含义RUNNABLE39线程正在运行或就绪等待 CPU 调度TIMED_WAITING(onobjectmonitor)21线程限时等待对象锁TIMED_WAITING(parking)6线程限时等待如 LockSupport.parkNanosTIMED_WAITING(sleeping)51线程限时休眠如 Thread.sleepWAITING(onobjectmonitor)305线程无限期等待对象锁Object.wait()WAITING(parking)3线程无限期等待如 LockSupport.park关键发现305 个线程处于WAITING(onobjectmonitor)状态占线程总数的绝大多数。第三步分析 WAITING 线程的具体行为查看线程栈信息打开dump文件一瞬间的信息查看处于WAITING(onobjectmonitor)状态的线程栈。关键栈信息示例http-0.0.0.0-7001-97 daemon prio10 tid0x000000004f6a8000 nid0x555e in Object.wait() [0x0000000052423000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method)根因定位这些线程是JBOSS 的工作线程都在执行Object.wait()方法处于等待状态。说明 JBOSS 线程池配置过大线程池里线程接收的任务太少大量线程都处于空闲等待状态。这些空闲线程会被操作系统频繁调度引发大量上下文切换消耗系统资源。第四步调整 JBOSS 线程池配置优化动作找到 JBOSS 的线程池配置文件将maxThreads最大工作线程数从250降低到100。关键配置示例解读maxThreads250 maxHttpHeaderSize8192 emptySessionPathfalse minSpareThreads40 maxSpareThreads75 maxPostSize512000 protocolHTTP/1.1 enableLookupsfalse redirectPort8443 acceptCount200 bufferSize16384 connectionTimeout15000 disableUploadTimeoutfalse useBodyEncodingForURItruemaxThreads线程池最大线程数原配置为 250优化后改为 100。minSpareThreads最小空闲线程数原配置为 40。maxSpareThreads最大空闲线程数原配置为 75。acceptCount等待队列长度原配置为 200。第五步验证优化效果操作步骤重启 JBOSS 服务使配置生效。再次使用jstack命令 dump 线程信息。统计处于WAITING(onobjectmonitor)状态的线程数量。优化结果WAITING状态的线程减少了 175 个。原理大量空闲线程减少后操作系统不需要频繁地在WAITING和RUNNABLE状态之间调度线程从而显著降低上下文切换次数。验证工具可使用vmstat命令观察cscontext switch列的数值变化确认上下文切换次数减少。死锁定义两个或多个线程互相持有对方需要的资源又都不肯释放自己已占有的资源导致所有线程永久阻塞、谁都无法继续执行程序卡死。二、死锁产生的四个必要条件必须同时满足才会死锁互斥条件资源同一时刻只能被一个线程占用别人不能抢。请求与保持条件线程已经持有至少一个资源又去请求新的资源不释放已占有的。不可剥夺条件资源只能由持有线程主动释放其他线程不能强行抢占。环路等待条件线程之间形成资源等待环路线程 A 等 B 的资源线程 B 等 A 的资源。只要破坏任意一个条件就能避免死锁。三、死锁产生常见场景多线程多把锁嵌套加锁顺序不一致线程互相持有对方需要的锁互相等待数据库多事务更新行加行锁顺序颠倒四、如何预防 / 避免死锁破坏四大条件统一加锁顺序所有线程按相同顺序获取多把锁从根源打破环路等待。主动释放资源申请新锁前先释放已持有锁破坏请求与保持。设置锁超时尝试加锁超时就放弃、回退不永久等待破坏不可剥夺。使用 tryLock 尝试获取锁拿不到锁就立刻放弃或重试不阻塞等待。减少嵌套锁尽量不写多重锁嵌套从业务上减少死锁概率。五、死锁如何排查jps查看 Java 进程 IDjstack 进程ID导出线程快照搜索Deadlock工具会自动检测并提示死锁线程查看线程栈看各自持有什么锁、等待什么锁定位代码位置Java并发机制的底层实现原理特性synchronizedvolatile主要作用保证原子性、可见性、有序性保证可见性、有序性不保证原子性适用场景多线程竞争下的复合操作如i状态标记、开关变量如boolean isRunning实现原理基于锁机制会阻塞其他线程基于内存屏障不会阻塞线程性能开销较高涉及锁竞争、线程上下文切换极低仅内存读写无阻塞是否能保证线程安全可以对代码块 / 方法加锁保证操作原子性仅在特定场景下无复合操作能保证✅synchronized读写都安全它能保证代码块 / 方法内的操作是原子性的同一时间只有一个线程能执行所以不管是读还是写操作都是线程安全的。⚠️volatile仅读安全写不安全尤其是复合写它只能保证变量的可见性和禁止指令重排序但不保证原子性单次读操作是安全的所有线程都能读到最新值。单次写操作如直接赋值flag true在特定场景下是安全的。复合写操作如count包含读 - 改 - 写三步完全不安全会出现线程安全问题关键概念可见性定义当一个线程修改了volatile修饰的共享变量其他线程能立刻读到最新值不会被 CPU 缓存或指令重排序延迟。底层原理写操作时强制将修改值刷回主内存读操作时强制从主内存读取最新值不使用 CPU 缓存避免了传统变量 “本地缓存副本” 导致的线程间数据不一致问题volatile的定义与实现原理一、volatile的定义背景Java 允许多线程访问共享变量为了保证变量更新的准确性和一致性通常需要通过排他锁如synchronized实现线程安全。volatile的定位Java 提供的一种更轻量、更便捷的同步机制在部分场景下可替代锁。核心语义如果一个字段被声明为volatileJava 线程内存模型会确保所有线程看到的这个变量的值是一致的即保证可见性。二、volatile的核心作用保证可见性多线程环境下当一个线程修改了volatile变量的值其他线程能立即感知到最新值不会因为 CPU 缓存或指令重排序导致 “读不到最新数据” 的问题。这也是它和普通变量最关键的区别之一。部分场景替代锁相比重量级锁如synchronizedvolatile使用更便捷、开销更低在无复合操作的场景下如状态标记可以替代锁实现线程安全。三、后续内容预告实现原理的底层支撑原文提到在深入讲解volatile的实现原理前会先介绍相关的 CPU 术语表 2-1这些术语是理解其底层实现的基础包括CPU 缓存L1/L2/L3 Cache缓存一致性协议如 MESI内存屏障Memory Barrier指令重排序等补充volatile的关键局限它不保证原子性对于count这类 “读 - 改 - 写” 复合操作volatile无法保证线程安全仍需使用锁或原子类如AtomicInteger。它不替代锁的全部功能仅适用于特定场景如状态标记、双重检查锁单例不能替代所有同步需求。术语英文核心作用 / 描述内存屏障memory barriers一组处理器指令限制内存操作的执行顺序是实现 volatile 有序性、可见性的核心底层指令。缓冲行缓存行cache lineCPU 缓存中可分配的最小存储单位处理器读写数据时会以整个缓存行为单位加载 / 写入数据。原子操作atomic operations不可被中断的单步或系列操作是实现无锁并发的基础。缓存行填充cache line fill处理器从内存读取数据时若数据可缓存会将整个缓存行加载到各级缓存L1/L2/L3。缓存命中cache hit后续访问的内存地址仍在缓存中处理器直接从缓存读取无需访问内存速度大幅提升。写命中write hit处理器写数据时目标地址已在缓存中直接写入缓存不写回内存。写缺失write misses the cache处理器写数据时目标地址不在缓存中需先加载缓存行再写入。1. 问题volatile 如何保证可见性图中明确指出要理解 volatile 的实现需要在X86 处理器下通过查看 JIT 编译器生成的汇编指令分析 volatile 变量写操作时 CPU 的行为。2. 核心底层机制补充完整volatile 的可见性和有序性本质上是通过内存屏障指令实现的写屏障Store Barrier在 volatile 变量写操作后插入强制将缓存中的修改刷回主内存并禁止后续指令重排序到写操作之前。读屏障Load Barrier在 volatile 变量读操作前插入强制从主内存读取最新值并禁止后续指令重排序到读操作之前。三、术语与 volatile 的关联内存屏障直接实现 volatile 的两大核心语义 —— 可见性强制刷写 / 读取主内存和有序性禁止指令重排序。缓存行 / 缓存一致性volatile 的写操作会触发缓存一致性协议如 MESI使其他 CPU 核心的缓存行失效被迫从主内存读取最新值从而保证可见性。原子操作volatile 不保证复合操作如count的原子性但单次读写操作本身是原子的依赖 CPU 的原子读写指令实现。volatile为什么不能保证准确性核心结论volatile 不保证原子性volatile只能保证可见性和禁止指令重排序但完全不保证复合操作的原子性。很多我们以为的 “简单操作”比如count在 CPU 层面其实是三步操作从主内存读取count的值到 CPU 缓存对值进行 1 计算将计算后的结果写回主内存而volatile只能保证第 1 步和第 3 步的 “可见性”但无法阻止多线程在第 1 步和第 3 步之间互相干扰导致数据丢失。