1. 别急着写代码先搞懂多线程到底在解决什么问题很多同学学Java多线程一上来就背Thread、Runnable、synchronized结果面试一问多线程解决了什么问题就卡壳。其实多线程的核心就一句话让多个任务同时执行把CPU的利用率榨干同时不搞乱共享数据。为什么需要多线程三个字太慢了。你从数据库查100万条数据要3秒如果串行一条条处理可能要几分钟。但如果你把这100万条数据拆成10个线程去处理每个线程只跑10万条理论上速度能提升接近10倍。这就是多线程的价值——用空间换时间用并发换吞吐。但天下没有免费的午餐。多线程带来的三大问题每一个都够你喝一壶的原子性问题i这行代码看着简单实际上在CPU层面是读取-修改-写回三步操作。两个线程同时执行i结果可能不是2而是1这就是典型的竞态条件Race Condition。可见性问题每个CPU核心都有自己的缓存。线程A改了变量flag true线程B在自己的缓存里看到的还是false。变量改了别人看不见这就是可见性失效。有序性问题编译器为了优化性能可能会对指令进行重排序。你以为先执行A再执行B实际执行顺序可能是B在A前面——这就是指令重排。这三大问题本质上是CPU架构缓存、指令流水线和Java内存模型JMM共同作用的结果。所以真正吃透多线程靠的不是背API而是理解**Java内存模型JMM和并发三大特性原子性、可见性、有序性**之间的关系。下面我用一个例子带你入门先把线程的基础操作玩明白再深入原理层面。1.1 创建线程的六种方式你会几种先来个最基础的开胃菜——创建线程。很多人张口就是两种继承Thread、实现Runnable。但实际面试官问创建线程有几种方式标准答案是四种如果算上线程池就是六种。// 方式1继承Thread class MyThread extends Thread { Override public void run() { System.out.println(方式1继承Thread); } } // 方式2实现Runnable class MyRunnable implements Runnable { Override public void run() { System.out.println(方式2实现Runnable); } } // 方式3实现Callable有返回值 class MyCallable implements CallableString { Override public String call() throws Exception { return 方式3实现Callable; } } // 方式4线程池 ExecutorService pool Executors.newFixedThreadPool(4); pool.submit(() - System.out.println(方式4线程池));我强烈建议优先使用方式2和方式3而不是直接继承Thread。为什么因为Java是单继承的你继承了Thread就不能再继承其他类了扩展性直接废掉。而且Runnable把任务和执行解耦了——任务归任务线程归线程以后想用线程池、想换并发策略任务代码完全不用动。Callable和Runnable最大的区别就是有返回值。你写一个计算任务算完想拿结果Runnable做不到它run()方法没有返回值只能通过共享变量兜圈子Callable直接返回Future阻塞拿结果优雅得很。FutureTaskString futureTask new FutureTask(new MyCallable()); new Thread(futureTask).start(); String result futureTask.get(); // 阻塞直到任务完成FutureTask.get()这个方法我要特别提醒一下——它是阻塞的。如果你在主线程里直接调get()主线程会傻等着子线程跑完。如果你有多个任务都调get()就变成了串行等待多线程白开了。正确姿势是先把任务全部submit()再统一get()。这个坑我踩过好几次后面讲线程池的时候还会再提。1.2 线程的生命周期不是只有运行和结束线程状态这个知识点面试必问但很多人搞不清BLOCKED和WAITING的区别。Java线程有六种状态用Thread.getState()就能看状态触发条件说明NEWnew Thread(...)线程创建但还没start()RUNNABLEstart()之后包含正在运行和等待CPU分配两种子状态BLOCKED没抢到synchronized锁卡在等锁上WAITING调用wait()/join()/park()无限期等待必须靠别人唤醒TIMED_WAITING调用sleep(ms)/wait(timeout)/join(ms)有时间限制的等待TERMINATEDrun()正常执行完或抛出异常线程已死亡我举个特别容易搞混的例子sleep()和wait()的区别。sleep()是Thread的方法不会释放锁。线程睡着了但锁还攥在手里别人进不来。wait()是Object的方法必须配合synchronized使用而且会释放锁。线程进等待池把锁交出去其他线程才有机会进来。这意味着什么如果你在synchronized代码块里调sleep(1000)其他线程这1秒内全部阻塞等锁等到花儿都谢了。而wait()则会把锁释放让其他线程先跑这才叫真正意义上的协作。还有一点RUNNABLE状态其实内部包含了**操作系统层面的运行中和就绪**两种状态Java层面不做区分。你去jstack看线程状态看到RUNNABLE只能说明线程没被阻塞/等待不能说明它正在跑。排查线上CPU飙高的时候这种细节能帮你少走很多弯路。2. synchronized与volatile最朴素的线程安全方案说到线程安全绝大多数人第一个想到的就是synchronized。这确实是最简单、最不容易出错的方案但它背后牵扯到的锁升级机制、监视器Monitor模型才是面试真正要考的深度。2.1 synchronized的三种用法和锁升级synchronized有且仅有三种使用场景// 1. 修饰实例方法锁的是this对象 public synchronized void methodA() { ... } // 2. 修饰静态方法锁的是Class对象 public static synchronized void methodB() { ... } // 3. 修饰代码块锁的是括号里的指定对象 public void methodC() { synchronized (lockObject) { ... } }这里面有个关键细节实例方法锁的是this静态方法锁的是Class这两把锁不是同一把。如果你的类同时有静态同步方法和实例同步方法它们是可以被两个线程并发执行的因为它们抢的是不同的锁。这个问题我在代码评审里见过好几个人踩坑。JDK 1.6对synchronized做了重大优化引入了偏向锁-轻量级锁-重量级锁的升级路径。简单理解偏向锁只有一个线程访问同步块锁会偏向这个线程后续它再来不需要做任何同步操作最省性能。轻量级锁有第二个线程来竞争了偏向锁升级为轻量级锁使用CAS自旋尝试抢锁不阻塞。重量级锁竞争进一步加剧锁升级为重量级锁底层依赖操作系统的mutex没抢到的线程进入BLOCKED状态涉及用户态和内核态切换性能最差。这里面有个非常重要的结论synchronized不是一开始就是重量级的。很多人听网上说synchronized性能差那是古董年代的说法。现在的synchronized经过锁升级优化后在低竞争场景下性能并不比ReentrantLock差多少。2.2 volatile比synchronized更轻但能力有限volatile可能是Java并发里最容易被误解的关键字了。它的定位是保证可见性和有序性但不保证原子性。看一个经典的反例public class Counter { private volatile int count 0; public void increment() { count; // 这不是原子操作 } }count是读-写-回三步操作volatile只能保证读的时候看到的是最新值但三步操作中间可能被其他线程穿插。两个线程同时执行increment()count可能只加了1。想用volatile实现计数器纯属自找麻烦——这种情况应该用AtomicInteger。那volatile到底适合什么场景状态标志位这是它的经典用法public class ShutdownHook { private volatile boolean shutdown false; public void shutdown() { shutdown true; // 写线程这个变量一改读线程立刻可见 } public void doWork() { while (!shutdown) { // 业务逻辑这里能看到最新的shutdown值 } } }为什么这里不能用synchronized不是不能是没必要。volatile的写操作不需要加锁不涉及线程阻塞性能开销极小而且语义上另一个线程改了个标志我要马上看到完全匹配volatile的设计初衷。关于内存屏障我多说两句。volatile之所以能保证可见性和有序性是因为编译器在生成指令时会插入内存屏障Memory Barrier。具体到Java内存模型的规则就是volatile写之前的普通读写不能重排到volatile写之后volatile读之后的普通读写不能重排到volatile读之前。这套规则还有个专门的名称叫happens-before原则。2.3 当年困扰我很久的happens-beforehappens-before是Java内存模型最核心的规则之一一共八条但实际工作中你只需要搞清楚最常用的几条程序次序规则同一个线程中前面的操作happens-before后面的操作。监视器锁规则解锁操作happens-before加锁操作。同一个锁上前一个线程释放锁后一个线程要获取同一把锁时前一个线程的所有修改都对后一个线程可见。volatile规则volatile变量的写操作happens-before后续对它的读操作。传递性A happens-before BB happens-before C则A happens-before C。用大白话翻译一下就是A线程对共享变量的所有修改如果满足happens-before规则那么在B线程是可以可见的。比如synchronized代码块里改了某个普通变量出了代码块其他线程不一定看得到但如果你两个线程都synchronized在同一个对象上前一个线程改完后一个线程进入代码块时一定能看到修改——这就是解锁happens-before加锁的含义。这个理论不仅面试要考实际排查线上问题也很有用。我记得有次排查一个偶发的数据错乱问题代码里各种synchronized用得很乱有个共享变量在同步块外被读取结果读到的永远是旧值。用happens-before一分析马上定位到问题根源——同步块外的读操作和同步块内的写操作之间没有任何happens-before关系。3. JUC并发工具包从AQS到并发容器如果说synchronized是基础武器那java.util.concurrent包简称JUC就是你的武器库。JUC的核心是AQSAbstractQueuedSynchronizer一个抽象的队列同步器整个JUC锁和同步工具的骨架都是它。3.1 AQS是怎么做到用状态机管理锁的AQS的核心设计非常精妙一个volatile int state变量 一个CLH等待队列 一套模板方法。state表示同步状态对于ReentrantLockstate表示锁被重入的次数对于Semaphorestate表示剩余许可数对于CountDownLatchstate表示还需等待的计数数。CLH队列是FIFO双向链表存放抢锁失败的线程。每个节点记录线程信息和等待状态线程在队列里通过自旋或阻塞等待被唤醒。模板方法如tryAcquire、tryRelease、tryAcquireShared、tryReleaseShared由子类实现具体的获取/释放逻辑。我自己用一张图来理解AQS它就是一个多线程排队领号系统。你来了尝试获取锁发现有人在处理业务state ! 0就先到候客厅CLH队列排队等着前面的处理完叫号前驱节点释放锁唤醒后继节点。这个设计的好处是加锁/解锁的核心排队逻辑只需要写一次各种同步工具只需要调整state的语义就行。拿ReentrantLock的加锁流程举例调用lock()实际执行sync.acquire(1)。acquire()先尝试一次tryAcquire(1)——如果当前锁没被持有CAS把state从0改为1拿到锁。如果尝试失败说明锁被占用了把当前线程封装成Node加入等待队列。入队后如果前驱节点是head再尝试一次tryAcquire(1)万一锁刚被释放呢。如果还是失败就把当前线程park挂起等前驱节点释放锁后再唤醒。你可能会问ReentrantLock和synchronized有什么区别用这个场景说明最直观ReentrantLock的加锁过程是可以先尝试、失败入队、被唤醒后重新抢锁整个过程非常灵活还支持公平锁、可中断、超时、多个条件队列等高级特性。而synchronized的加锁是JVM字节码层面的monitorenter/monitorexit很多底层逻辑黑盒扩展性差。3.2 ReentrantLock与synchronized的选择指南我从实际项目的角度给你一个简单粗暴的选择标准对比维度synchronizedReentrantLock锁获取方式隐式字节码自动加锁/解锁显式手动lock()和unlock()中途中止不支持支持lockInterruptibly()超时尝试不支持支持tryLock(timeout, unit)公平性非公平支持公平/非公平条件队列只能配合wait()/notify()使用单一条件支持多个Condition对象性能JDK1.6后低竞争场景表现良好高竞争场景更稳定我个人的经验是能用synchronized就别用ReentrantLock。因为synchronized是JVM层面自动管理锁的出了异常多线程环境下异常太常见了JVM会自动释放锁而ReentrantLock如果你忘了在finally里unlock()锁永远不会释放直接导致死锁。这种低级错误在生产环境里是灾难级的。但反过来如果你需要尝试加锁加不上就放弃这种逻辑synchronized做不到你必须用tryLockLock lock new ReentrantLock(); if (lock.tryLock(3, TimeUnit.SECONDS)) { try { // 拿锁成功的业务逻辑 } finally { lock.unlock(); // 务必要在finally里释放 } } else { // 加锁超时走降级逻辑 log.warn(获取锁超时降级处理); }这种写法在分布式场景、API降级保护里特别实用——宁可超时降级也不能因为一个线程阻塞连累整个应用。3.3 并发容器与工具类面试高频菜JUC包里还有一批面试必问的类我把它们浓缩成一个清单ConcurrentHashMap线程安全的HashMapJDK1.8之后放弃了分段锁改用CAS synchronized锁桶头节点。读操作基本无锁性能远超Hashtable。记住一个关键点它不允许null键或null值和HashMap不同。CopyOnWriteArrayList读多写少的场景适用。写操作复制一份新数组做修改读操作完全不加锁适用于缓存列表、白名单这类低频写场景。代价就是每次写都复制数组如果写频繁就别用了内存开销太大。CountDownLatch让一个线程等待多个线程执行完再继续。经典的用法是主线程等所有子线程跑完再汇总结果CountDownLatch latch new CountDownLatch(3); for (int i 0; i 3; i) { new Thread(() - { try { /* 执行任务 */ } finally { latch.countDown(); } }).start(); } latch.await(); // 主线程阻塞等3个子线程全部countDown System.out.println(三个任务全部完成);注意countDown()一定要放进finally里——万一子线程抛异常countDown没执行主线程会永远await这就是线上卡死的常见元凶之一。CyclicBarrier多个线程互相等待都到齐了之后一起执行一个屏障动作。和CountDownLatch最大的区别是可循环使用而且没有await()的次数上限。典型场景多线程分批处理分页数据每处理完一批大家碰个头再处理下一批。Semaphore信号量控制同时访问某个资源的线程数量。比如限流场景同时只允许3个线程访问数据库连接池Semaphore semaphore new Semaphore(3); for (int i 0; i 10; i) { new Thread(() - { try { semaphore.acquire(); // 只有3个线程能同时执行到这里 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { semaphore.release(); } }).start(); }另外ThreadLocal也值得一提它是空间换时间、线程隔离的代表方案。每个线程持有自己的变量副本互不干扰。但要注意使用ThreadLocal之后一定要remove()否则在线程池场景下线程复用会导致上次的数据残留而且如果ThreadLocal里存了大的对象还可能引发脏数据和内存泄漏。4. 线程池生产环境并发编程的第一选择我一直跟组里的同学说生产代码里不要轻易裸用new Thread()优先用线程池。裸建线程有三个问题反复创建销毁线程开销大、线程数量不受控可能把CPU和内存干趴、上层没有统一管理手段比如优雅停机、监控。4.1 七个参数的排列组合决定线程池的一切ThreadPoolExecutor有七个参数每个都有讲究new ThreadPoolExecutor( corePoolSize, // 核心线程数即使空闲也保留 maximumPoolSize, // 最大线程数 keepAliveTime, // 非核心线程空闲存活时间 TimeUnit.SECONDS, // 时间单位 new LinkedBlockingQueue(1000), // 等待队列 Executors.defaultThreadFactory(), // 线程工厂 new ThreadPoolExecutor.AbortPolicy() // 拒绝策略 );这七个参数的执行逻辑我用一句话总结先来先用核心线程接活核心线程不够了往队列里排队队列满了再开非核心线程去接最后还是接不下就触发拒绝策略。我见过很多团队直接Executors.newFixedThreadPool()一把梭。这个快捷方法虽然省事但有两个隐患一是队列用的是无界队列LinkedBlockingQueue任务积压时会把内存撑爆二是newCachedThreadPool()的最大线程数是Integer.MAX_VALUE并发洪峰直接把系统打挂。所以生产环境更推荐手动构造ThreadPoolExecutor并显式设置有界队列和拒绝策略。拒绝策略我没具体说明这里有四种可以选择AbortPolicy直接抛RejectedExecutionException适合关键任务宁可报错也不能静默丢弃。CallerRunsPolicy任务回退到调用者线程执行简单说就是你自己不帮忙就等着相当于一种天然的限流。DiscardPolicy静默丢弃适合非重要日志类任务。DiscardOldestPolicy丢弃队头最老的任务腾位置给新任务。4.2 核心线程数到底该设多少这个问题几乎是面试必问你这个线程池核心线程数为什么设为10如果你答我凭感觉拍的就完了。合理的推导有两条路线CPU密集型任务线程数 CPU核数 1。计算吃CPU线程开多了反而因为上下文切换拖慢速度。IO密集型任务线程数 CPU核数 × (1 平均等待时间 / 平均计算时间)。IO操作在等网络/磁盘这期间CPU闲着多开线程正好把空闲的CPU补上。如果无法精确统计就用经验公式CPU核数 × 2。用我自己的一个业务场景举例8核机器上跑一个主要做HTTP调用的任务平均耗时200ms其中网络等待约150ms计算约50ms。那么合理的线程数大约是8 * (1 150/50) 32。这个数字比网上说的8核就8个线程靠谱得多因为IO密集型任务的核心线程是要把等待时间也利用起来的。线程数设置完后还需要配合监控线上看看线程池的活跃线程数、队列积压情况、拒绝任务数。如果拒绝任务数经常大于0说明线程数偏小或者队列太小需要调整参数。4.3 线程池工厂和优雅停机一个容易被忽略的细节设置线程池时强烈建议自定义ThreadFactory给线程起个有业务含义的名字。否则线上排查问题你会疯掉——jstack一看全是pool-1-thread-1你根本不知道哪个线程属于哪个业务。ThreadFactory namedFactory new ThreadFactory() { private final AtomicInteger seq new AtomicInteger(1); Override public Thread newThread(Runnable r) { Thread t new Thread(r); t.setName(order-process-thread- seq.getAndIncrement()); t.setDaemon(false); return t; } };线程池的优雅停机也是生产环境的必修课。应用发布的时候如果直接杀进程线程池里没跑完的任务可能丢一大片。正确姿势是// 先禁止新任务提交 pool.shutdown(); // 等待正在执行的任务结束最多等30秒 if (!pool.awaitTermination(30, TimeUnit.SECONDS)) { // 超时还没结束强制关闭 pool.shutdownNow(); }shutdown()和shutdownNow()的区别是前者等已提交的任务跑完后者直接尝试中断所有正在跑的任务。绝大多数场景先用shutdown()实在拖太久才考虑shutdownNow()因为在执行的任务可能持有数据库连接、文件句柄等资源强行中断会产生一堆半成品状态。5. 数据一致性与并发编程的实战避坑指南回到开头的三大问题——原子性、可见性、有序性。我前面讲了很多理论但实际代码里处理数据一致性还需要掌握CAS和原子类以及一些典型的并发反模式。5.1 CAS与Atomic原子类无锁编程的基石AtomicInteger这类原子类底层的实现是CASCompare And Swap。它的逻辑很简单要修改一个值之前先比较当前内存里的值和预期值相等才更新不相等就重新读取再试自旋。整个过程是通过CPU的一条原子指令完成的不需要加锁。AtomicInteger count new AtomicInteger(0); count.incrementAndGet(); // 相当于 i但这是原子操作CAS最大的问题是ABA问题线程A读到值是A线程B把它改成B又改回A线程A再CAS时看到的还是A但它其实已经变了。解决方式是用AtomicStampedReference带版本号。不过实际业务里碰到ABA的场景其实不多更多是因为业务本身要记录变量变化历史。使用AtomicInteger时需要注意如果逻辑复杂、循环自旋次数多CAS还是会浪费CPU此时要考虑是否值得。LongAdder在高并发场景比AtomicLong更优秀。它的设计是分段计数多个线程各自在自己的段上累加最后sum()把所有段的值加起来。读多写少的场景表现一般但并发激烈、写并发量大的时候它比AtomicLong的CAS自旋要稳得多。5.2 ThreadLocal怎么用才不会翻车前面我提过ThreadLocal要记得remove()这里展开讲一下为什么。ThreadLocalMap的key是ThreadLocal对象弱引用但value是强引用。如果线程一直存活线程池里的线程就是这样key被回收而value还在这个value会一直停留在Map里形成内存泄漏。正确用法是这样的try { ThreadLocalString context ThreadLocal.withInitial(() - ); context.set(用户A的信息); // 业务逻辑 } finally { context.remove(); // 无论成功失败都清掉 }另外一个ThreadLocal使用的误区是把大对象丢进去。ThreadLocal本质是线程私有变量的缓存区塞一个几MB的对象进去每个线程各存一份几百个线程就是几百MB内存。轻则GC压力大重则OOM。我在一次方案评审里看到有人用ThreadLocal缓存数据库连接池的对象赶紧喊停——ThreadLocal适合存小型的、线程私有的上下文信息不适合存重量级资源。5.3 死锁、活锁与并发写Redis这类经典问题死锁的经典场景是两个线程互相持有对方需要的锁。我用一个每个人都听得懂的类比有两个人面对面过独木桥都先跨出了左脚结果卡在桥中间谁都不肯先收脚——因为你收脚就意味着让路。排查死锁的工具很简单jstack命令里面会明确报告Found one Java-level deadlock同时给出两个线程互相等待锁的栈信息。避免死锁的通用策略有几点破坏持有并等待一次性申请所有需要的锁申请不到就释放已有的。对应代码就是tryLock循环尝试。破坏互斥尽量用无锁数据结构和原子类代替锁。破坏循环等待所有线程都按固定顺序加锁。比如两个资源A和B约定先加锁A再加锁B就不会出现A-等待B、B-等待A的环形局面。最后谈一个并发面试中被反复问到的场景多个线程同时写Redis的同一个key怎么保证数据一致。这个问题的核心不是Redis而是跨线程的原子性问题。如果操作是get - 业务计算 - set三个步骤不是原子的并发下必然互相覆盖。解决思路一般是三种之一用分布式锁把三步串行化用Redis的incr/lua脚本把原子操作下沉到Redis端用时间戳比较只允许最新时间戳的写入生效。这三种方案里最推荐的是利用Lua脚本做原子操作因为分布式锁有锁失效、误删锁等一堆边界问题而Lua脚本是Redis自身保证原子性的。6. 面试高频考点和排查工具速查这篇文章快写完了最后我把自己面试别人和被人面试的经验整理成一份高频清单和高频排查工具版图。这些不只是用来背的更是日常开发中真正能用的。6.1 高频面试题别只会背答案面试官问多线程的时候从来不是想听你背定义而是想看你有没有真正用多线程解决过问题。下面是几道出现频率极高的题我附带点评问题1Thread.sleep(0)有意义吗有。它的作用是主动触发一次CPU重新调度让出当前线程的时间片。虽然和时间无关但在高并发测试中可以用它来制造更多线程切换机会。问题2synchronized和ReentrantLock怎么选前面表格已经说清楚了但面试时要答出偏向锁升级tryLock超时可中断锁Condition多条件队列这些关键词才算答出深度。问题3ConcurrentHashMap为什么不允许null值因为并发场景下如果get()返回null你无法区分是key不存在还是value本来就是null。这会引发二义性在多线程环境里没法容忍这种不确定性。这也是它和HashMap的一个关键差异。问题4ThreadLocal为什么会出现内存泄漏一句话说明原因ThreadLocalMap的key是弱引用但value是强引用当ThreadLocal被置空后key会被GCvalue却不会造成Entry的value滞留在Map中。线程本身不销毁value就永远不被回收。问题5什么是伪共享False Sharing这个问题比较进阶。CPU缓存以缓存行为单位通常64字节如果两个线程操作的是不同的变量但它们恰好在同一个缓存行里其中一个线程修改该缓存行会导致另一个线程的缓存行失效不得不重新从内存加载。这就是伪共享。解决办法是对变量做Contended填充或者手动补充字段。面试能答出这一步基本算高分了。6.2 线上排查jstack、jstat、arthas三板斧多线程问题排查最怕的是复现不了。线上偶发的卡顿、死锁、线程数飙高本地一跑就好。我建议你掌握下面几个工具的使用思路jstack pid拿到Java进程的线程快照立刻能看到每个线程的状态、锁等待情况、死锁检测信息。看到大量WAITING线程且堆栈指向同一把锁基本就是锁竞争问题了。看到RUNNABLE且CPU占用高可能就是死循环或GC问题。jstat -gcutil pid 1000每秒打印GC信息如果Full GC频繁那多线程只是个表象真正的问题是内存分配太快导致GC成为瓶颈。Arthas阿里开源诊断工具里的thread -n 3命令可以直接找出CPU占用最高的前三个线程并打印其堆栈用来定位哪个线程在疯狂跑。还有watch命令可以观测方法入参和返回值帮助排查并发环境下的数据不一致。生产环境装好Arthas排查效率会翻几倍。排查经验里我最想强调的一点是很多并发问题不是锁不够而是锁太多了。线程一个个全阻塞在锁上系统看起来像是死了实际是锁的粒度过大把并发压没了。我见过一个报表模块初始化时把所有数据都加一把大锁平时没问题一旦数据量翻倍所有线程全在排队。后来把锁粒度细化到每个分片几十毫秒就搞定。所以排查看现象更要从设计上反思——是不是锁的粒度还能拆得更细是不是能换用无锁方案是不是并发本身就没必要。最后再补充一个小技巧排查线程问题顺序一定要先看监控再看堆栈后看代码。监控曲线能告诉你问题发生的时间窗口堆栈能告诉你哪个线程卡住最后才轮到代码层面分析为什么卡。一上来就翻代码往往事倍功半。这个顺序我踩过太多次教训希望你能少走弯路。