Java高并发核心面试题及详细答案（真实面试版）

Java高并发核心面试题及详细答案（真实面试版）一、Java并发基础核心面试题1.简述进程和线程的区别，以及为什么线程开销比进程小？参考答案：进程是操作系统资源分配的最小单位，线程是CPU调度的最小单位。核心区别有三点：1）资源隔离：进程之间完全独立，拥有独立的内存空间、堆、文件句柄等资源；同一个进程内的多个线程共享堆、方法区、常量池，仅私有栈、程序计数器、局部变量表独立。2）开销不同：进程创建、销毁、切换需要操作系统重新分配资源、刷新页表，开销极大；线程共享进程资源，切换只需要保存少量栈和寄存器信息，开销非常小。3）通信方式不同：进程间通信复杂，需要管道、Socket、共享内存等方式；线程之间直接共享变量即可通信，简单高效。线程开销小的核心原因：线程没有独立的资源，所有资源依托父进程，切换和创建无需操作系统重量级资源操作。2.说说并发和并行的区别？参考答案：并发是同一时间段内多个任务交替执行，单核CPU也能实现，通过CPU快速切换线程，让用户看起来是同时运行的，本质是交替执行。并行是同一时刻多个任务同时执行，必须依赖多核CPU，多个核心真正同时运行不同线程。简单总结：并发是“交替做”，并行是“一起做”；并行一定是并发，并发不一定是并行。3.Java线程的生命周期有哪些状态？分别是什么场景？参考答案：Java线程一共6种状态，定义在Thread.State枚举中：1）NEW（新建）：线程对象创建完成，未调用start()方法，未启动。2）RUNNABLE（可运行）：调用start()后，包含两种情况：正在CPU运行、等待CPU时间片。Java把就绪和运行状态统一合并为RUNNABLE。3）BLOCKED（阻塞）：线程等待获取synchronized重量级锁，锁被其他线程占用时进入该状态。6）TERMINATED（终止）：线程代码执行完毕或异常退出，生命周期结束，无法再次启动。4.wait、sleep、yield的核心区别？（高频）参考答案：1）所属类不同：sleep、yield是Thread类静态方法；wait是Object类方法。2）锁行为不同：wait会释放当前锁；sleep、yield不释放任何锁。这是面试最核心考点。3）唤醒机制不同：sleep限时自动唤醒；wait无超时需要notify/notifyAll唤醒；yield只是让出本次CPU时间片，立刻回到就绪状态。4）使用场景不同：sleep用于线程休眠；wait用于多线程等待协作；yield只是临时让出CPU，不保证礼让成功。5）异常要求：sleep需要捕获InterruptedException；wait、yield无需强制捕获。二、Java内存模型与线程安全面试题1.什么是JMM（Java内存模型）？核心作用是什么？参考答案：JMM是Java官方定义的一套多线程内存读写规范，不是硬件内存模型，是逻辑抽象模型。主要用来解决多线程下可见性、原子性、有序性问题。JMM核心规定：所有变量存储在主内存，每个线程有自己的工作内存（缓存）。线程读写变量必须先从主内存拷贝到工作内存，操作完成后再刷新回主内存，线程之间不能直接读写对方工作内存数据。核心作用：屏蔽不同硬件和操作系统的内存差异，保证Java多线程程序在所有平台下内存语义一致。2.并发三大特性：原子性、可见性、有序性，分别解释及失效场景参考答案：原子性：一个操作或多个操作要么全部执行成功，要么全部不执行，不可中断。失效场景：i++复合操作（读取、修改、写入三步），多线程下会出现覆盖，失去原子性。synchronized、Atomic类可以保证原子性。可见性：一个线程修改共享变量后，其他线程能立刻感知到最新值。失效场景：普通变量存在工作内存缓存，一个线程修改后未刷新主内存，其他线程读取旧值。volatile、synchronized可以保证可见性。有序性：程序执行顺序按照代码书写顺序执行。失效场景：CPU和编译器会做指令重排（无依赖指令打乱执行顺序），多线程下会出现逻辑错乱。volatile可以禁止指令重排，保证有序性。3.volatile关键字的作用、优缺点，能不能保证线程安全？参考答案：volatile核心三大作用：1）保证共享变量可见性，修改后立刻刷新主内存，其他线程实时读取最新值；2）禁止指令重排序，避免多线程重排导致的逻辑异常；3）不保证原子性。不能保证线程安全，典型例子：volatile修饰的i++，依旧会出现计数不准，因为i++是三步复合操作，volatile只能保证可见性，无法保证整体原子性。优点：轻量级、无锁、开销极小，适合状态标记、开关变量等场景。缺点：无法处理复合操作，不能替代锁，使用场景有限。4.什么是指令重排？为什么会导致并发问题？参考答案：指令重排是编译器、CPU为了提升执行效率，在不影响单线程执行结果的前提下，打乱代码指令的执行顺序。单线程下重排无任何问题，但多线程共享变量场景下，会出现逻辑错乱。最经典案例：双重检查锁单例模式，不加volatile时，可能出现对象半初始化问题。编译器重排会把「对象分配内存、初始化、赋值引用」顺序打乱，导致其他线程获取到未初始化完成的对象，引发空指针或数据异常。三、锁机制核心面试题（synchronized、Lock）1.synchronized的底层原理？锁升级机制详细说参考答案：synchronized是JVM层面的内置锁，基于对象头的MarkWord实现，JDK1.6之后引入锁升级机制，优化了之前的重量级锁性能问题，锁状态不可逆：无锁→偏向锁→轻量级锁→重量级锁。1）偏向锁：单线程竞争场景，默认开启。偏向锁会记录当前线程ID，后续该线程再次获取锁无需CAS，直接放行，无任何开销。适合单线程重复加锁场景。2）轻量级锁：出现多线程竞争，偏向锁撤销，升级为轻量级锁。基于自旋CAS实现，线程不阻塞，循环尝试获取锁，用户态执行，开销小。适合竞争不激烈、锁持有时间短的场景。3）重量级锁：自旋失败、竞争激烈、自旋次数过多，升级为重量级锁。依赖操作系统互斥量，线程阻塞进入内核态，开销大，会有线程排队等待。补充：锁只能升级不能降级，目的是保证高并发下的性能稳定性。2.synchronized和ReentrantLock的区别？什么时候用Lock？参考答案：1）底层实现：synchronized是JVM内置锁，底层C++实现；ReentrantLock是JDK层面的锁，基于AQS队列实现，Java代码可控。2）可重入性：两者都是可重入锁。3）公平锁：synchronized默认非公平，无法修改；ReentrantLock支持公平/非公平锁自定义。4）中断响应：synchronized阻塞后无法中断；ReentrantLock支持lockInterruptibly()，可以响应线程中断，避免死等。5）超时获取锁：ReentrantLock支持tryLock(time)，超时自动放弃，避免死锁；synchronized不支持。6）条件队列：ReentrantLock可以绑定多个Condition，精准唤醒指定线程；synchronized只能通过notify/notifyAll随机唤醒，无法精准控制。使用场景选择：简单同步、代码块优先用synchronized；需要公平锁、超时锁、可中断锁、精准唤醒、复杂并发控制时，必须用ReentrantLock。3.什么是死锁？死锁产生的四个必要条件？如何避免？参考答案：死锁是多个线程互相持有对方需要的锁，同时等待对方释放锁，所有线程永久阻塞，程序卡死。四个必要条件，缺一不可：1）互斥条件：锁同一时刻只能被一个线程持有；2）请求与保持：线程持有旧锁，同时请求新锁，不释放已有锁；3）不可剥夺：锁只能持有者主动释放，其他线程不能强行抢占；4）循环等待：多个线程形成闭环锁等待链。避免方案：1）统一锁的获取顺序，打破循环等待；2）使用tryLock超时获取，避免永久等待；3）减少嵌套锁，尽量不多个锁嵌套；4）定时检测死锁线程，主动释放资源。四、AQS与JUC核心组件面试题1.简述AQS核心原理？AQS是什么，解决什么问题？参考答案：AQS全称抽象队列同步器，是JUC包下所有锁和并发工具的底层核心（ReentrantLock、CountDownLatch、Semaphore底层都基于AQS）。AQS核心设计：一个volatile修饰的state状态变量+一个FIFO双向阻塞队列。1）state变量：核心资源标识，不同组件含义不同。ReentrantLock中代表锁重入次数；CountDownLatch中代表剩余计数；Semaphore中代表剩余许可数。2）双向队列：获取锁失败的线程会封装成Node节点，进入队列阻塞排队，等待资源释放后被唤醒。AQS核心思想：通过CAS修改state状态实现资源抢占，失败则入队阻塞，成功则执行业务，统一规范了并发资源竞争、阻塞、唤醒的逻辑，避免重复造轮子。2.CountDownLatch、CyclicBarrier、Semaphore区别及使用场景参考答案：1.CountDownLatch一次性计数器，线程等待所有任务执行完成后统一唤醒，计数器归零后不可重置。场景：主线程等待多个子线程任务全部执行完毕，再继续往下执行。2.CyclicBarrier可循环屏障，多个线程互相等待，所有线程到达屏障点后统一放行，支持重复使用。场景：多线程分阶段执行，每一步所有线程就绪后再进入下一阶段，比如批量分片处理数据。3.Semaphore信号量，控制并发线程数量，限制资源访问频次，支持限流。场景：接口限流、数据库连接池、资源抢占限流，控制同时访问资源的线程数。3.AtomicInteger底层原理？为什么能保证原子性？参考答案：AtomicInteger底层基于CAS无锁自旋实现，不使用synchronized和Lock，性能极高。CAS核心逻辑：比较并交换，包含三个参数（内存值V、旧预期值A、新值B）。只有当内存值V等于预期值A时，说明变量未被其他线程修改，才会更新为新值B；否则自旋重试，直到更新成功。同时变量使用volatile修饰，保证可见性和有序性，结合CAS的原子操作，整体保证并发安全。缺点：存在ABA问题、自旋空转消耗CPU、只能保证单个变量原子性。五、线程池核心面试题（重中之重）1.线程池核心参数详细解释？参考答案：ThreadPoolExecutor七大核心参数：1）corePoolSize：核心线程数，线程池常驻线程，即使空闲也不会回收。2）maximumPoolSize：最大线程数，线程池允许创建的最大线程数量。3）keepAliveTime：非核心线程空闲超时时间，超时未任务则被回收。4）unit：超时时间单位。5）workQueue：任务阻塞队列，存放等待执行的任务，常用ArrayBlockingQueue、LinkedBlockingQueue。6）threadFactory：线程工厂，用来创建线程，可自定义线程名称、优先级、守护线程。7）handler：拒绝策略，任务队列满、线程数达到最大值后，新任务的处理策略。2.线程池执行流程？参考答案：1）提交任务后，判断当前运行线程数是否小于核心线程数，小于则新建核心线程执行任务；2）核心线程已满，尝试将任务加入阻塞队列；3）队列已满，无法存入任务，判断当前线程数是否小于最大线程数，小于则新建非核心线程执行任务；4）线程数已达到最大值，队列也已满，触发拒绝策略处理新任务。3.四种默认拒绝策略？各自特点参考答案：1）AbortPolicy（默认）：直接抛出RejectedExecutionException异常，终止任务，适合对任务丢失零容忍场景。2）CallerRunsPolicy：谁提交任务谁执行，不抛异常、不丢弃，适合流量削峰。3）DiscardPolicy：直接丢弃新任务，无异常、无日志，适合不重要的后台任务。4）DiscardOldestPolicy：丢弃队列最头部最旧的未执行任务，尝试执行新任务。4.为什么禁止使用Executors创建线程池？生产如何配置？参考答案：阿里开发手册明确禁止使用Executors快捷创建线程池，核心原因是存在资源耗尽风险：1）newFixedThreadPool、newSingleThreadExecutor：使用无界队列LinkedBlockingQueue，任务无限堆积，会导致OOM内存溢出。2）newCachedThreadPool、newScheduledThreadPool：最大线程数无限，高并发下会创建大量线程，导致CPU爆满、线程耗尽、服务宕机。生产规范：手动通过ThreadPoolExecutor构造方法创建，自定义核心参数、有界队列、拒绝策略，规避OOM和线程爆炸问题。5.核心线程数如何合理设置？参考答案：根据任务类型区分，公式只是参考，最终以压测为准：1）CPU密集型任务（计算多、IO少）：核心线程数=CPU核心数+1，避免频繁上下文切换，充分利用CPU。2）IO密集型任务（数据库、网络请求多）：核心线程数=CPU核心数*2或CPU核心数/(1-阻塞系数)，IO阻塞时线程空闲，多开线程提升吞吐量。实际生产必须结合压测调整，根据接口吞吐量、CPU负载、队列堆积情况优化参数。六、并发实战与高频坑点面试题1.HashMap为什么线程不安全？JDK1.7和1.8的并发问题区别？参考答案：HashMap全程无锁，多线程put、扩容、遍历都会出现线程安全问题。JDK1.7问题：多线程扩容会出现链表环形死循环，导致CPU100%，同时会出现数据覆盖、丢失问题。JDK1.8问题：优化了扩容逻辑，解决了环形链表问题，但依旧线程不安全。多线程put会发生数据覆盖，多线程扩容会导致数据丢失，无法保证并发安全。并发场景必须使用ConcurrentHashMap。2.ConcurrentHashMapJDK1.7和1.8底层区别？参考答案：1）锁粒度不同：1.7采用分段锁（Segment分段数组），默认16个分段，最多同时16个线程写；1.8废弃分段锁，采用数组+链表+红黑树结构，锁粒度细化到单个数组桶，并发度大幅提升。2）锁实现不同：1.7分段继承ReentrantLock；1.8使用synchronized+CAS，偏向锁、轻量级锁优化，性能优于重入锁。3）数据结构：1.7是数组+链表；1.8新增红黑树，链表长度超过8、数组长度大于64转为红黑树，查询效率从O(n)优化为O(logn)。4）扩容机制：1.8支持多线程协助扩容，提升扩容效率。3.什么是ABA问题？如何解决？参考答案：ABA问题是CAS的经典漏洞：线程1读取变量值为A，线程2先将A修改为B，再改回A，线程1CAS比对时发现值还是A，认为变量未被修改，正常更新，导致隐藏的数据异常。解决方案：1）添加版本号，每次修改版本号自增，比对时同时校验值和版本号；2）JDK提供AtomicStampedReference、AtomicMarkableReference，自带版本戳，彻底解决ABA