Java线程并发高频面试题及详细答案（实战版）

Java线程并发高频面试题及详细答案（实战版）一、线程基础核心面试题1.说说进程和线程的区别？这是并发最基础的问题，核心区别在于资源隔离和调度粒度：1）进程：是操作系统资源分配的最小单位，每个进程有独立的内存空间、堆、文件句柄等资源，进程之间完全隔离，互不干扰。进程切换开销极大，需要保存完整的进程上下文。2）线程：是CPU调度的最小单位，一个进程包含多个线程，线程共享当前进程的堆内存、方法区、全局变量，仅私有栈、程序计数器、本地变量表。线程切换开销极小，只需要保存少量线程上下文。简单总结：进程是资源容器，线程是执行单元；进程隔离、线程共享，进程开销大、线程轻量。2.线程的生命周期有哪些状态？分别是什么场景？Java线程一共6种状态，源码定义在Thread.State枚举中，日常面试重点区分阻塞、等待、超时等待的差异：1）NEW（新建）：线程对象创建完成，未调用start()方法，未启动。2）RUNNABLE（可运行）：包含就绪和运行两种状态，调用start()后进入该状态，等待CPU调度执行。3）BLOCKED（阻塞）：线程等待获取synchronized重量级锁，锁被其他线程占用时进入阻塞，锁释放后立即争抢。6）TERMINATED（终止）：线程代码执行完毕，或异常终止，生命周期结束。3.start()和run()方法的区别？1）run()：只是一个普通的成员方法，直接调用只会在当前主线程中串行执行，不会开启新线程，多次调用可重复执行。2）start()：是开启新线程的核心方法，会向操作系统申请线程资源，由JVM调用native方法启动线程，线程进入就绪状态。start()只能调用一次，第二次调用会抛出IllegalThreadStateException异常。核心区别：run是业务逻辑方法，start是创建线程、启动线程的方法。4.sleep()和wait()的核心区别？这是面试高频对比题，核心差异在锁、唤醒机制、所属类：1）所属类不同：sleep是Thread类静态方法；wait是Object类方法，所有对象都有。2）锁释放不同：sleep休眠时不释放锁，持有锁休眠，其他线程无法获取锁；wait执行后立即释放锁，其他线程可以竞争锁。3）唤醒方式不同：sleep超时自动唤醒；wait需要被notify()/notifyAll()唤醒，或限时wait超时唤醒。4）使用场景不同：sleep用于单纯延时；wait用于线程间通信、条件等待。5）异常要求：sleep必须捕获InterruptedException；wait同样需要捕获，且必须在同步代码块中执行。二、并发安全与锁机制面试题1.什么是线程安全？线程不安全的根本原因？线程安全：多线程并发操作共享资源时，程序运行结果和单线程执行结果一致，不会出现数据错乱、脏数据。不安全根本原因：Java中赋值、自增等操作并非原子操作，多线程下存在三大问题：1）原子性：操作被拆分，多线程交替执行，数据覆盖；2）可见性：线程缓存数据，主内存数据更新后，其他线程无法及时感知；3）有序性：编译器、CPU指令重排，打乱代码执行顺序，导致逻辑异常。2.synchronized底层原理？锁升级机制详细说一下synchronized是JVM层面的内置锁，基于对象头的MarkWord实现，为了提升性能，引入了锁升级机制，锁状态从无锁偏向锁→轻量级锁→重量级锁逐步升级，只能升级不能降级。1）偏向锁：无竞争场景，默认开启。假设全程只有一个线程竞争锁，MarkWord记录线程ID，后续该线程再次获取锁无需CAS操作，直接放行，无开销。2）轻量级锁：出现多线程竞争，偏向锁升级为轻量级锁。基于CAS自旋抢锁，不阻塞线程，适合竞争不激烈、执行速度快的场景，自旋消耗少量CPU资源。3）重量级锁：竞争激烈、自旋次数过多，升级为重量级锁。依赖操作系统互斥量，未抢到锁的线程直接阻塞，进入内核态，开销大，适合高并发竞争场景。补充：synchronized修饰普通方法锁对象实例，修饰静态方法锁类对象，修饰代码块锁指定对象。3.synchronized和ReentrantLock的区别？实际项目怎么选？两者都是可重入锁，核心区别如下：1）底层实现：synchronized是JVM原生锁，底层依赖对象头；ReentrantLock是JDK代码层面实现，基于AQS队列。2）功能灵活性：ReentrantLock功能更强，支持公平锁/非公平锁切换、可中断锁、超时锁、多条件变量Condition；synchronized仅支持非公平锁，功能单一。3）锁释放：synchronized自动释放锁，无需手动处理，不会死锁；ReentrantLock必须手动unlock()释放，否则永久占用锁，极易死锁。4）性能：JDK1.6之后synchronized做了锁升级优化，性能和ReentrantLock基本持平，低竞争场景更优。项目选型：简单同步场景优先用synchronized，代码简洁安全；需要公平锁、超时抢锁、精准唤醒线程、高并发竞争场景，用ReentrantLock。4.volatile关键字的作用？能保证原子性吗？volatile核心作用两点：保证可见性、禁止指令重排，不保证原子性。1）可见性：修饰变量后，线程修改变量会立即刷新到主内存，其他线程读取时直接从主内存读取，跳过本地缓存，解决多线程数据不可见问题。2）有序性：通过内存屏障，禁止编译器和CPU对变量前后指令重排，解决单例模式双重检查锁的空指针问题。3）不保证原子性：自增、复合赋值等操作是读-改-写三步操作，volatile只能保证每次读取最新值，无法保证三步操作不可分割，多线程下依然会出现数据覆盖。适用场景：状态标记量、读写分离场景（单写多读）。5.什么是死锁？产生死锁的四个必要条件？如何避免？死锁：多个线程互相持有对方需要的锁，同时等待对方释放锁，所有线程永久阻塞，程序卡死。四个必须同时满足的必要条件：1）互斥条件：锁资源同一时间只能被一个线程持有；2）请求与保持条件：线程持有已有锁，同时请求新锁，不释放旧锁；3）不可剥夺条件：锁只能被持有者主动释放，其他线程无法强制抢占；4）循环等待条件：多个线程形成闭环锁等待关系。避免方案：1）破坏循环等待：统一锁的获取顺序，所有线程按固定顺序抢锁；2）破坏请求保持：一次性申请所有需要的锁，不分批获取；3）使用超时锁：ReentrantLock.tryLock(timeout)，超时自动放弃抢锁；4）减少嵌套锁：尽量避免锁嵌套使用。三、JUC并发工具类面试题1.AQS原理是什么？核心结构和工作流程？AQS（抽象队列同步器）是JUC所有锁和并发工具的底层核心，ReentrantLock、CountDownLatch、Semaphore底层都依赖AQS。核心结构：1）state变量：volatile修饰的int值，代表同步状态，0表示无锁，大于0表示有锁、可重入次数；2）双向阻塞队列：存放所有抢锁失败的线程，线程封装为Node节点；3）独占/共享模式：独占模式仅限一个线程获取锁（ReentrantLock），共享模式允许多线程同时获取锁（CountDownLatch、Semaphore）。工作流程：线程抢锁时，通过CAS修改state值，修改成功则获取锁；修改失败则封装为Node节点加入阻塞队列，挂起等待；持有锁的线程释放锁后，唤醒队列中首个线程，继续竞争锁。2.CountDownLatch、CyclicBarrier、Semaphore的区别和使用场景？1）CountDownLatch（倒计时计数器）核心：一次性计数器，初始化设置数值，线程执行完countDown()减1，主线程await()等待计数器归0后继续执行，不可重置复用。场景：主线程等待多个子线程执行完毕，再统一执行后续逻辑。2）CyclicBarrier（循环栅栏）核心：可循环复用的屏障，指定线程数，所有线程到达屏障点后，统一唤醒继续执行，计数归零后自动重置，可重复使用。场景：多线程分批执行，每批线程全部就绪后再统一下一步，比如批量数据处理、多任务分段执行。3）Semaphore（信号量）核心：控制并发线程数量，初始化设置许可数，线程acquire()获取许可、release()释放许可，限制同时执行的线程数。场景：接口限流、资源抢占控制，比如数据库连接池、限流秒杀场景。3.ConcurrentHashMap底层原理？JDK1.7和1.8区别？ConcurrentHashMap是线程安全的键值对集合，解决HashMap线程不安全、HashTable效率低的问题。JDK1.7：采用分段锁机制，将集合分为16个Segment分段，每个分段独立加锁，不同分段可并发操作，并发度为16，底层是数组+链表。JDK1.8：废弃分段锁，采用数组+链表+红黑树，锁粒度细化到数组桶位：1）无冲突时，CAS无锁操作；2）单桶位出现冲突，对链表头节点加synchronized锁；3）链表长度超过8、数组容量大于64，链表转为红黑树，提升查询效率；4）扩容采用多线程协助扩容机制，提升并发扩容效率。核心优化：锁粒度更小、并发度更高、查询速度更快，彻底解决1.7分段锁并发上限问题。四、线程池核心面试题1.为什么要用线程池？手动newThread有什么问题？手动创建线程弊端非常明显：1）频繁创建、销毁线程开销极大，浪费CPU和内存资源；2）无限制创建线程，会导致线程数量过多，系统OOM、线程耗尽、程序卡死；3）无法统一管理线程，无法控制并发数、监控任务执行状态。线程池核心优势：1）复用线程，减少创建销毁开销；2）控制最大并发线程数，保护系统资源；3）统一管理任务，支持延时、定时、批量任务执行；4）提供拒绝策略、异常处理机制，提升程序稳定性。2.线程池七大核心参数、执行流程详细说七大参数：1）corePoolSize：核心线程数，线程池常驻线程，不会被回收；2）maximumPoolSize：最大线程数，线程池允许创建的最大线程数量；3）keepAliveTime：非核心线程空闲超时时间，超时自动回收；4）unit：超时时间单位；5）workQueue：任务阻塞队列，存放等待执行的任务；6）threadFactory：线程工厂，用于创建线程，可自定义线程名、优先级；7）handler：拒绝策略，任务满了之后的处理策略。执行流程：1）提交任务，判断当前线程数是否小于核心线程数，是则直接创建核心线程执行任务；2）核心线程已满，判断任务队列是否已满，队列未满则将任务存入队列等待；3）队列已满，判断当前线程数是否小于最大线程数，是则创建非核心线程执行任务；4）线程数已达到最大值，队列也已满，触发拒绝策略。3.线程池四种拒绝策略？各自适用场景？1）AbortPolicy（默认）：直接抛出RejectedExecutionException异常，中断任务提交，适合核心任务，不允许丢失任务。2）CallerRunsPolicy：谁提交任务谁执行，由主线程自行执行任务，不丢弃、不报错，适合非核心任务，平缓削峰。3）DiscardPolicy：直接丢弃新任务，无异常、无日志，适合不重要、可丢弃的日志、统计类任务。4）DiscardOldestPolicy：丢弃队列中最旧的未执行任务，替换为新任务，适合时效性高、新任务优先级更高的场景。4.实际开发中为什么禁止使用Executors创建线程池？阿里开发规范明确禁止使用Executors快捷创建线程池，核心原因是存在OOM风险：1）newFixedThreadPool、newSingleThreadExecutor：队列采用无界LinkedBlockingQueue，任务无限堆积，内存溢出；2）newCachedThreadPool、newScheduledThreadPool：最大线程数为Integer.MAX_VALUE，可无限创建线程，导致线程溢出、系统卡死。开发规范：必须通过ThreadPoolExecutor手动创建线程池，自定义核心参数、有界队列、拒绝策略，规避风险。五、并发高阶面试题（实战高频）1.线程池核心线程数怎么设置？生产环境配置经验根据任务类型区分配置，没有固定数值，结合CPU核心数调整：1）CPU密集型任务：大量计算、极少IO，核心线程数=CPU核心数+1，避免CPU频繁切换，最大化利用算力；2）IO密集型任务：数据库查询、接口调用、文件读写，线程大量时间阻塞，核心线程数=CPU核心数*2或核心数/(1-阻塞系数)；3）混合任务：拆分IO和CPU任务，分开配置线程池，避免互相阻塞。生产建议：优先压测调优，初始按公式配置，根据任务耗时、CPU负载、队列堆积情况动态调整。2.如何解决线程池任务异常丢失问题？线程池执行任务时，若任务抛出未捕获异常，普通线程池会直接终止线程、新建线程替换，无任何日志，异常静默丢失，线上问题极难排查。解决方案：1）任务内部手动try-catch捕获所有异常，打印日志；2）自定义线程工厂，重写线程的uncaughtException方法，统一捕获未捕获异常；3）使用submit提交任务，通过Future.get()主动捕获执行异常；4）重写线程池afterEx