Java高级_资深_架构岗 核心知识点（模块三：高并发）

Java高级_资深_架构岗 核心知识点（模块三：高并发）

核心提示：本模块学习的关键是「理解高并发的本质与痛点、掌握Java高并发基础API的底层原理、能结合生产场景选型高并发组件、具备高并发系统的设计与优化能力」，面试时无需死记硬背API用法，重点掌握「底层原理+实践场景+踩坑经验」，结合生产案例说明，体现落地能力。本模块将严格参考模块一的格式，分为「底层理论、实践落地、最佳实践」三个部分，聚焦2026年面试高频考点，兼顾专业性与落地性，助力快速掌握核心内容，从容应对架构岗追问。

一、底层理论（通俗解读，聚焦2026年面试高频，不搞无用讲解）

高并发的底层理论，核心是「高并发的本质、核心指标、Java高并发基础、高并发核心组件原理」，这也是面试的重中之重。以下内容完全贴合2026年行业趋势，剔除过时的并发技术细节，重点拆解面试官常问的核心原理，用通俗的语言讲解，避免专业术语堆砌，让你既能说清底层，又能贴合实践，同时建立完整的高并发知识体系。

1. 高并发核心定义与本质（面试必说）

通俗解读：高并发（High Concurrency）是指系统在「单位时间内接收大量用户请求」，并能高效处理这些请求，不出现响应超时、系统崩溃、数据错乱等问题的能力。比如电商双11，每秒可能有几十万、上百万的下单请求，系统能稳定处理这些请求，就是高并发能力的体现。

• ① 高并发的核心本质（面试加分）：

• 本质是「解决"请求量大"与"系统处理能力有限"的矛盾」------ 单线程、单体系统的处理能力有限（如单线程每秒只能处理几百个请求），而高并发场景需要系统每秒处理几千、几万甚至几十万请求，因此需要通过"多线程、分布式部署、组件优化"等方式，提升系统的整体处理能力，分摊请求压力。

• 核心矛盾：高并发场景下，「性能、可用性、数据一致性」的平衡------ 追求高性能（快响应），可能会牺牲部分数据一致性（如最终一致性）；追求强数据一致性，可能会牺牲部分性能（如分布式锁导致的延迟）；追求高可用，需要增加节点冗余，提升系统复杂度。

② 高并发核心衡量指标（面试必背，2026年高频）：

• QPS（Queries Per Second）：每秒查询数，指系统每秒能处理的请求数量，是衡量高并发能力的核心指标（如QPS=10000，代表系统每秒能处理10000个请求）；

• TPS（Transactions Per Second）：每秒事务数，指系统每秒能处理的事务数量，适合衡量带业务逻辑的请求（如下单、支付，一个事务可能包含多个查询/操作）；

• 响应时间（Response Time）：从用户发起请求到系统返回响应的总时间，衡量系统的响应速度（如接口响应时间≤50ms，用户无感知；≤300ms，用户体验良好）；

• 并发量：系统同时处理的请求数量（如并发量=1000，代表系统同一时刻有1000个请求正在处理）；

• 吞吐量（Throughput）：单位时间内系统处理的总数据量（如每秒处理100MB数据），结合QPS/TPS，全面衡量系统处理能力；

• 可用性（Availability）：系统在高并发场景下的稳定运行时间占比，常用"几个9"衡量（如99.9%可用性，代表每年故障时间不超过8.76小时；99.99%，不超过52.56分钟）；

• 错误率：单位时间内处理失败的请求占比（如错误率≤0.1%，代表每1000个请求中，失败不超过1个），高并发场景下错误率需严格控制。

③ 高并发与高可用的区别（面试必问）：

• 高并发：侧重「处理能力」，解决"请求多"的问题，保证系统能快速处理大量请求（核心指标：QPS、响应时间）；

• 高可用：侧重「稳定性」，解决"系统不崩溃"的问题，保证系统在高并发、节点故障、网络异常时，仍能正常提供服务（核心指标：可用性、错误率）；

• 关联：高并发是高可用的前提（无高并发需求，高可用意义不大），高可用是高并发的保障（高并发场景下，系统崩溃则无意义），两者缺一不可。

2. Java高并发基础（面试重中之重，底层基石）

Java作为高并发系统开发的首选语言，其内置的并发基础（线程、锁、线程池）是构建高并发系统的核心，2026年面试重点考察这些基础的底层原理、用法、优缺点，以及常见踩坑点，是理解后续高并发组件的前提。

（1）Java线程核心基础（面试必说）

线程是Java并发编程的最小单位，高并发本质是"多线程并行/并发处理请求"，掌握线程的核心概念与用法，是入门高并发的第一步。

• ① 线程与进程的区别（面试必问）：

• 进程：操作系统资源分配的最小单位（如一个Java程序就是一个进程），每个进程有独立的内存空间、CPU资源，进程之间相互独立，通信成本高；

• 线程：进程内的执行单元，是CPU调度的最小单位，多个线程共享进程的内存空间（堆、方法区），共享资源，通信成本低，切换成本远低于进程；

• 核心关联：一个进程可以包含多个线程（如Java程序的主线程、GC线程、业务线程），线程的生命周期依赖于进程，进程终止，所有线程均终止。

② 线程的生命周期（面试必背，结合状态切换）：

• 新建状态（New）：创建Thread对象（如new Thread()），未调用start()方法，线程未启动；

• 就绪状态（Runnable）：调用start()方法后，线程等待CPU调度（此时线程已具备执行条件，只需获取CPU时间片）；

• 运行状态（Running）：线程获取CPU时间片，执行run()方法中的业务逻辑；

• 阻塞状态（Blocked）：线程因某种原因（如等待锁、等待IO、sleep()）放弃CPU使用权，暂停执行，直到阻塞条件解除，进入就绪状态；

• 常见阻塞场景：synchronized锁等待（Blocked状态）、Object.wait()（Waiting状态）、Thread.sleep(long)（Timed Waiting状态）；

终止状态（Terminated）：线程执行完run()方法，或被中断（interrupt()）、异常终止，线程生命周期结束，无法再次启动。

③ Java线程的创建方式（面试必说，2026年高频）：

• 方式1：继承Thread类，重写run()方法（缺点：无法多继承，灵活性低，生产环境几乎不用）；

• 方式2：实现Runnable接口，重写run()方法（优点：可多实现，灵活性高，无返回值，适合简单并发场景）；

• 方式3：实现Callable接口，重写call()方法（优点：可多实现，有返回值，可抛出异常，适合需要获取线程执行结果的场景，如异步任务）；

• 方式4：使用线程池（ExecutorService）创建线程（2026年生产主流，优点：线程可复用，控制线程数量，避免线程创建/销毁成本过高，后续重点讲解）；

• 面试延伸：Callable与Runnable的区别？------ ① Callable有返回值，Runnable无返回值；② Callable可抛出异常，Runnable不可抛出异常；③ Callable需配合Future/FutureTask获取返回值。

④ 线程的核心操作（面试必说）：

• start()：启动线程，将线程从新建状态转为就绪状态，交给CPU调度（不可重复调用，否则抛出IllegalThreadStateException）；

• run()：线程执行的核心方法，包含业务逻辑（直接调用run()方法，不会启动新线程，只是普通方法调用）；

• sleep(long millis)：线程休眠指定时间（毫秒），期间放弃CPU使用权，进入Timed Waiting状态，休眠结束后进入就绪状态（不会释放已持有的锁）；

• wait()：线程进入Waiting状态，放弃CPU使用权和已持有的锁，需通过notify()/notifyAll()唤醒，唤醒后进入就绪状态；

• notify()/notifyAll()：唤醒等待的线程（notify()唤醒一个随机等待线程，notifyAll()唤醒所有等待线程）；

• interrupt()：中断线程（并非强制终止线程，只是设置线程的中断标志位，线程可通过isInterrupted()判断，自行终止）；

• join()：等待该线程执行完成后，再执行其他线程（如主线程等待子线程执行完，再继续执行）。

（2）Java并发锁核心原理（面试重中之重，高并发数据安全保障）

高并发场景下，多个线程同时操作共享资源（如库存、余额、全局计数器），会出现数据错乱（如超卖、少扣减），而并发锁的核心作用是「保证共享资源的互斥访问（同一时间只有一个线程能操作共享资源）」，解决数据一致性问题。2026年面试重点考察不同锁的分类、底层原理、优缺点、适用场景，以及锁优化技巧。

① 锁的核心分类（面试必背，按维度区分）

• 维度1：按锁的获取方式（核心分类）：

• 乐观锁：假设没有并发冲突，操作共享资源时不加锁，仅在提交时检查是否有冲突（如通过版本号、CAS实现）；优点：无锁竞争，性能高；缺点：冲突时需重试，适合并发冲突少的场景（如商品详情查询、用户信息修改）；

• 悲观锁：假设一定有并发冲突，操作共享资源时先加锁，阻止其他线程操作，直到释放锁；优点：数据一致性高，无重试成本；缺点：锁竞争激烈，性能低，适合并发冲突多的场景（如库存扣减、支付）。

维度2：按锁的作用范围：

• 本地锁：仅作用于当前进程内的线程，解决单个JVM进程内的并发冲突（如synchronized、Lock）；

• 分布式锁：作用于多个分布式节点（多个JVM进程），解决分布式场景下的并发冲突（如Redis分布式锁、ZooKeeper分布式锁，后续分布式模块详细讲解）。

维度3：按锁的实现方式（Java本地锁）：

• synchronized锁：Java内置锁，隐式锁（自动加锁、释放锁），底层基于对象监视器（Monitor）实现；

• Lock锁：Java并发包（java.util.concurrent.locks）提供的显式锁（手动加锁、释放锁，需try-finally保证释放），如ReentrantLock、ReadWriteLock。

维度4：其他常见分类：

• 可重入锁：线程获取锁后，可再次获取该锁（无需释放），避免死锁（如synchronized、ReentrantLock，都是可重入锁）；

• 公平锁：线程获取锁的顺序，遵循"先到先得"（如ReentrantLock(true)），优点：公平，无饥饿；缺点：性能低；

• 非公平锁：线程获取锁的顺序不固定，随机竞争（如synchronized、ReentrantLock(false)默认），优点：性能高；缺点：可能出现线程饥饿（部分线程长期获取不到锁）；

• 读写锁（ReadWriteLock）：分为读锁（共享锁）和写锁（排他锁），多个线程可同时获取读锁（无冲突），只有一个线程能获取写锁（排他），适合"读多写少"的场景（如商品详情查询、新闻阅读）；

• 自旋锁：线程获取锁失败时，不进入阻塞状态，而是循环尝试获取锁（减少线程切换成本），底层基于CAS实现（如Unsafe类的CAS操作），适合锁持有时间短的场景。

② synchronized锁底层原理（面试必说，2026年高频）

• 核心定位：Java内置隐式锁，无需手动释放锁（代码执行完自动释放，异常时也会自动释放），易用性高，适合简单并发场景，JDK 1.8对其进行了大幅优化（偏向锁、轻量级锁、重量级锁），性能接近Lock锁。

• 底层实现：基于「对象监视器（Monitor）」和「对象头（Mark Word）」实现，每个Java对象都有一个对象头，对象头中存储了锁的状态（无锁、偏向锁、轻量级锁、重量级锁）；

• JDK 1.8锁优化（面试重点，锁升级过程）：

• 无锁状态：对象未被任何线程锁定，对象头中Mark Word存储对象哈希值、分代年龄；

• 偏向锁：当只有一个线程多次获取锁时，启用偏向锁，将线程ID存储在对象头Mark Word中，后续该线程获取锁时，无需竞争，直接获取（减少锁竞争成本）；

• 轻量级锁：当有两个线程竞争锁时，偏向锁升级为轻量级锁，线程通过CAS操作修改对象头Mark Word的锁状态，获取锁（无阻塞，循环尝试）；

• 重量级锁：当多个线程激烈竞争锁（超过两个），轻量级锁升级为重量级锁，依赖对象监视器（Monitor）实现，线程获取锁失败时进入阻塞状态（锁竞争成本高，性能低）；

• 核心优化目的：减少锁竞争的成本，根据并发冲突的激烈程度，动态切换锁的状态，兼顾易用性和性能。

synchronized的使用场景（面试必说）：

• 修饰方法：分为修饰实例方法（锁是当前对象this）和静态方法（锁是当前类的Class对象）；

• 修饰代码块：锁是括号中的对象（如synchronized (this)、synchronized (Object.class)），灵活控制锁的作用范围（推荐使用，减少锁粒度，提升性能）。

③ Lock锁核心原理（面试必说，2026年高频）

• 核心定位：Java并发包提供的显式锁，需手动加锁（lock()）和释放锁（unlock()，必须放在finally中，避免锁泄漏），灵活性高，支持多种锁特性（公平/非公平、可中断、超时获取锁），适合复杂并发场景。

• 核心实现类（面试必背）：

• ReentrantLock：可重入锁，支持公平锁和非公平锁（默认非公平），底层基于AQS（AbstractQueuedSynchronizer）实现，性能与synchronized相当（JDK 1.8后）；

• ReentrantReadWriteLock：可重入读写锁，包含ReadLock（读锁，共享锁）和WriteLock（写锁，排他锁），适合"读多写少"场景；

• StampedLock：JDK 1.8新增，优化的读写锁，支持乐观读模式，性能比ReentrantReadWriteLock更高，适合高并发读场景（如电商商品详情）。

核心底层AQS原理（面试重点，通俗解读）：

• AQS（AbstractQueuedSynchronizer）：抽象队列同步器，是Lock锁、线程池等并发组件的底层基础，核心由「状态变量（state）+ 同步队列（CLH队列）」组成；

• 状态变量（state）：用于表示锁的状态（如state=0，无锁；state=1，有锁；state>1，可重入锁的重入次数）；

• 同步队列（CLH队列）：用于存储获取锁失败的线程，是一个双向链表，线程获取锁失败时，进入队列尾部阻塞，锁释放时，唤醒队列头部的线程，尝试获取锁。

synchronized与Lock的区别（面试必问，2026年高频）：

• 锁的获取/释放：synchronized隐式锁（自动加锁、释放），Lock显式锁（手动加锁、释放，需try-finally）；

• 灵活性：Lock更高，支持公平/非公平锁、可中断锁、超时获取锁、条件变量（Condition）；synchronized仅支持非公平锁（默认）、可重入锁；

• 性能：JDK 1.8前，Lock性能优于synchronized；JDK 1.8后，synchronized经过优化，性能与Lock相当；

• 锁粒度：两者均可控制锁粒度（synchronized代码块、Lock锁对象），但Lock更灵活；

• 适用场景：synchronized适合简单并发场景（如简单的共享变量修改），Lock适合复杂并发场景（如需要超时获取锁、中断锁、读写分离）。

④ CAS核心原理（面试必说，乐观锁底层）

CAS（Compare And Swap，比较并交换）是乐观锁的核心底层实现，也是Java并发编程的基础（如AtomicInteger、Lock锁、线程池都依赖CAS），2026年面试重点考察CAS的原理、优缺点、ABA问题及解决方案。

• 核心原理（通俗解读）：CAS是一种无锁算法，包含三个参数（内存地址V、预期值A、新值B），执行时，先比较内存地址V中的值是否等于预期值A，若等于，则将V中的值替换为新值B；若不等于，则不做任何操作，返回false，线程可循环重试（自旋）。

• 核心优点：无锁竞争，无需线程阻塞，减少线程切换成本，性能高，适合并发冲突少的场景；

• 核心缺点（面试必说）：

• ABA问题：内存地址V中的值先从A变为B，再从B变为A，CAS判断时，认为值未变（仍为A），从而执行替换操作，导致数据错乱（如原子类的自增，可能出现重复自增）；

• 自旋开销：CAS获取锁失败时，线程会循环重试（自旋），若并发冲突激烈，自旋会占用大量CPU资源；

• 只能保证单个变量的原子性：CAS只能对单个共享变量执行原子操作，无法保证多个变量的原子性（如同时修改两个共享变量，需配合锁实现）。

ABA问题解决方案（面试必说）：

• 方式1：使用版本号（Version）：给共享变量增加一个版本号，每次修改变量时，版本号自增，CAS判断时，同时比较"变量值+版本号"，只有两者都相等，才执行替换操作（如数据库乐观锁的版本号机制）；

• 方式2：使用Java并发包中的AtomicStampedReference类：该类封装了"变量值+时间戳（类似版本号）"，CAS操作时，同时比较变量值和时间戳，避免ABA问题。

CAS的应用场景（面试必说）：

• 原子类：如AtomicInteger、AtomicLong、AtomicReference，实现共享变量的原子操作（如全局计数器、原子修改对象引用）；

• Lock锁：ReentrantLock底层依赖CAS实现锁的获取与释放；

• 线程池：线程池的核心状态（如运行、关闭、终止）切换，依赖CAS实现原子操作。

（3）Java线程池核心原理（面试重中之重，2026年生产主流）

高并发场景下，频繁创建和销毁线程会产生巨大的性能开销（线程创建需要分配内存、CPU资源，销毁需要释放资源），而线程池的核心作用是「线程复用，控制线程数量，管理线程生命周期」，避免线程创建/销毁的开销，提升系统高并发处理能力，是生产环境高并发编程的首选。2026年面试重点考察线程池的核心参数、工作原理、拒绝策略、常见线程池、踩坑点及优化。

① 线程池核心参数（面试必背，ThreadPoolExecutor）

Java线程池的核心实现类是ThreadPoolExecutor，其构造方法包含7个核心参数，每个参数都直接影响线程池的工作机制和性能，面试时需能准确说明每个参数的含义和作用。

• corePoolSize（核心线程数）：线程池中长期存活的线程数量（即使线程空闲，也不会销毁，除非设置了allowCoreThreadTimeOut(true)）；

• maximumPoolSize（最大线程数）：线程池中允许存在的最大线程数量（核心线程数+非核心线程数，非核心线程是临时创建的，空闲时会销毁）；

• keepAliveTime（非核心线程空闲时间）：非核心线程空闲后的存活时间，超过该时间，非核心线程会被销毁，释放资源；

• unit（空闲时间单位）：keepAliveTime的时间单位（如TimeUnit.SECONDS、TimeUnit.MILLISECONDS）；

• workQueue（任务队列）：用于存储等待执行的任务，当所有核心线程都在忙碌时，新提交的任务会进入任务队列等待；

• 常见队列类型（面试必说）：

• ArrayBlockingQueue：有界队列（固定容量），适合对线程池并发量有严格控制的场景（如电商库存扣减），避免任务堆积导致内存溢出；

• LinkedBlockingQueue：无界队列（默认容量Integer.MAX_VALUE），适合任务量不确定、并发冲突少的场景（如用户注册），但可能导致任务堆积，内存溢出；

• SynchronousQueue：同步队列，不存储任何任务，新提交的任务必须立即有线程执行（无空闲线程则创建新线程，直到达到最大线程数），适合任务执行时间短、并发量高的场景（如RPC调用）；

• PriorityBlockingQueue：优先级队列，任务按优先级排序执行，适合对任务执行顺序有要求的场景。

threadFactory（线程工厂）：用于创建线程的工厂类，可自定义线程名称、优先级、是否为守护线程（如命名线程为"order-thread-pool-1"，便于日志排查）；

handler（拒绝策略）：当线程池达到最大线程数，且任务队列已满，新提交的任务会被拒绝，拒绝策略用于处理被拒绝的任务（面试必说，4种内置拒绝策略）。

② 线程池拒绝策略（面试必说，4种内置策略）

拒绝策略是线程池的核心特性之一，当线程池处于饱和状态（最大线程数+任务队列已满）时，新提交的任务会触发拒绝策略，2026年面试重点考察4种内置拒绝策略的含义、优缺点、适用场景。

• AbortPolicy（默认拒绝策略）：直接抛出RejectedExecutionException异常，阻止系统正常运行，适合对任务可靠性要求高的场景（如支付、下单），及时发现问题；

• CallerRunsPolicy（调用者运行策略）：被拒绝的任务由提交任务的线程（如主线程）自行执行，避免任务丢失，适合任务量不大、对性能要求不高的场景（如日志打印）；缺点：可能阻塞调用者线程，影响系统响应；

• DiscardPolicy（丢弃策略）：直接丢弃被拒绝的任务，不抛出异常，也不执行，适合任务无关紧要、可丢失的场景（如日志收集、数据统计）；缺点：任务丢失，无法感知；

• DiscardOldestPolicy（丢弃最老任务策略）：丢弃任务队列中最老的任务（队列头部的任务），然后将新任务加入队列，尝试再次提交，适合任务队列有优先级、新任务比老任务更重要的场景（如实时消息推送）；缺点：可能丢弃重要的老任务。

③ 线程池工作原理（面试必说，核心流程）

线程池的工作流程是核心考点，面试时需能清晰拆解"新任务提交后，线程池的处理步骤"，结合核心参数，说明线程的创建、任务的执行、队列的作用。

1. 新任务提交后，线程池首先判断当前线程数是否小于核心线程数（corePoolSize）：若小于，创建核心线程，执行该任务；若不小于，进入下一步；

2. 判断任务队列（workQueue）是否已满：若未满，将任务加入队列，等待核心线程空闲后执行；若已满，进入下一步；

3. 判断当前线程数是否小于最大线程数（maximumPoolSize）：若小于，创建非核心线程，执行该任务；若不小于，进入下一步；

4. 触发拒绝策略（handler），处理被拒绝的任务（如抛出异常、丢弃任务）；

5. 非核心线程执行完任务后，进入空闲状态，空闲时间超过keepAliveTime，非核心线程被销毁，释放资源；核心线程继续保持空闲，等待新任务。

④ 常见线程池（面试必说，Executors工具类）

Java提供Executors工具类，封装了4种常见的线程池，方便快速创建，但生产环境不推荐直接使用（存在性能隐患），面试时需说明每种线程池的特点、隐患及替代方案。

• FixedThreadPool（固定线程数线程池）：

• 核心参数：corePoolSize = maximumPoolSize（固定线程数），keepAliveTime=0（非核心线程空闲立即销毁，此处无核心线程与非核心线程区别），队列使用LinkedBlockingQueue（无界队列）；

• 特点：线程数固定，任务队列无界，适合任务量稳定、执行时间较长的场景；

• 隐患：无界队列可能导致任务堆积，占用大量内存，最终引发OOM；

• 替代方案：使用ThreadPoolExecutor，手动设置核心参数，使用有界队列（如ArrayBlockingQueue）。

CachedThreadPool（可缓存线程池）：

• 核心参数：corePoolSize=0，maximumPoolSize=Integer.MAX_VALUE（无限大），keepAliveTime=60秒，队列使用SynchronousQueue（同步队列）；

• 特点：无核心线程，非核心线程无限多，任务执行完后空闲60秒销毁，适合任务执行时间短、并发量波动大的场景（如RPC调用、接口请求）；

• 隐患：maximumPoolSize无限大，并发量过高时，会创建大量线程，导致CPU、内存耗尽，系统崩溃；

• 替代方案：使用ThreadPoolExecutor，手动设置maximumPoolSize（如CPU核心数*2），控制线程数量。

SingleThreadExecutor（单线程线程池）：

• 核心参数：corePoolSize=1，maximumPoolSize=1，队列使用LinkedBlockingQueue（无界队列）；

• 特点：只有一个核心线程，任务队列无界，任务按顺序执行，适合需要保证任务顺序、无并发冲突的场景（如日志写入、数据同步）；

• 隐患：无界队列可能导致任务堆积，引发OOM；单线程故障，所有任务阻塞；

• 替代方案：使用ThreadPoolExecutor，设置corePoolSize=1，maximumPoolSize=1，使用有界队列。

ScheduledThreadPool（定时任务线程池）：

• 核心参数：corePoolSize固定，maximumPoolSize=Integer.MAX_VALUE，队列使用DelayedWorkQueue（延迟队列）；

• 特点：用于执行定时任务、周期性任务（如定时清理缓存、定时统计数据）；

• 隐患：maximumPoolSize无限大，可能创建大量线程；延迟队列任务堆积，引发OOM；

• 替代方案：使用ThreadPoolExecutor的子类ScheduledThreadPoolExecutor，手动设置maximumPoolSize和有界队列。

面试延伸：生产环境为什么不推荐使用Executors创建线程池？------ 因为Executors封装的线程池，要么使用无界队列（可能OOM），要么设置maximumPoolSize无限大（可能创建大量线程，耗尽资源），无法灵活控制线程池参数，存在性能隐患；推荐使用ThreadPoolExecutor手动创建，根据业务场景自定义核心参数。

3. 高并发核心组件（面试重中之重，生产落地核心）

仅依靠Java并发基础（线程、锁、线程池），无法解决大规模高并发场景（如每秒10万+请求）的问题，需要结合高并发核心组件，分摊请求压力、提升系统性能、保证高可用。2026年面试重点考察这些组件的核心原理、适用场景、主流工具，以及组件之间的协同使用。

（1）缓存（高并发性能优化核心，面试必说）

缓存的核心作用是「将高频访问、不易变化的数据，存储在内存中，用户请求时直接从内存获取，避免频繁访问数据库/磁盘」，减少IO开销，大幅提升系统响应速度（内存访问速度是磁盘的10万+倍）。缓存是高并发系统的"性能加速器"，几乎所有高并发系统都离不开缓存（如电商商品详情、用户信息、热点数据）。

• ① 缓存核心分类（面试必背，按存储位置）：

• 本地缓存：存储在当前JVM进程的内存中（如HashMap、Caffeine、Guava Cache），优点：访问速度最快（无网络开销）；缺点：仅作用于单个JVM，分布式场景下数据不一致，缓存容量有限；

• 分布式缓存：存储在独立的缓存服务器集群中（如Redis、Memcached），优点：支持分布式部署，缓存容量大，数据可共享，适合分布式高并发场景；缺点：有网络开销，访问速度略低于本地缓存；

• 多级缓存：结合本地缓存和分布式缓存（如本地缓存→Redis→数据库），兼顾访问速度和数据一致性，是2026年生产环境主流方案（如电商商品详情缓存）。

② 主流缓存工具（面试必说，2026年高频）：

• 本地缓存：

• Caffeine：Java高性能本地缓存，JDK 1.8+，性能优于Guava Cache，支持自动过期、缓存淘汰（LRU变体算法），适合高并发本地缓存场景（生产首选）；

• Guava Cache：Google开源的本地缓存，功能全面，但性能略低于Caffeine，适合老项目、低并发场景。

分布式缓存：

• Redis：2026年生产主流分布式缓存，支持多种数据结构（String、Hash、List、Set、ZSet），支持持久化、集群部署、分布式锁，兼顾缓存、消息队列、分布式协调功能，适合各种高并发场景；

• Memcached：老牌分布式缓存，仅支持String数据结构，不支持持久化，性能优异，但功能单一，适合简单的分布式缓存场景（逐渐被Redis替代）。

③ 缓存核心问题（面试必说，踩坑重点）：

• 缓存穿透：用户请求的数据，缓存中没有，数据库中也没有（如恶意请求不存在的商品ID），导致所有请求都穿透到数据库，数据库压力激增，甚至崩溃；

• 解决方案（面试必说）：① 缓存空值（缓存不存在的商品ID，设置短期过期）；② 布隆过滤器（提前过滤不存在的请求，避免穿透到数据库）；③ 接口参数校验（拦截恶意请求）。

缓存击穿：热点数据（如热门商品、热门活动）的缓存过期，此时大量用户请求同时穿透到数据库，导致数据库压力激增；

• 解决方案（面试必说）：① 热点数据永不过期；② 缓存续期（如定时任务，在缓存过期前，自动更新缓存）；③ 互斥锁（多个请求同时穿透时，只有一个请求能访问数据库，其他请求等待缓存更新）。

缓存雪崩：大量缓存数据在同一时间过期，或缓存服务器集群故障，导致所有请求都穿透到数据库，数据库崩溃；

• 解决方案（面试必说）：① 缓存过期时间随机化（避免大量缓存同时过期）；② 缓存集群部署（避免单点故障，如Redis集群）；③ 多级缓存（本地缓存兜底，即使分布式缓存故障，本地缓存仍能提供服务）；④ 限流降级（缓存故障时，限制请求流量，避免数据库崩溃）。

缓存一致性：缓存中的数据与数据库中的数据不一致（如修改数据库数据后，未及时更新缓存），导致用户获取到旧数据；

• 解决方案（面试必说）：① 先更新数据库，再删除缓存（推荐，避免缓存脏写）；② 延迟双删（先删缓存，再更数据库，延迟一段时间再删一次缓存，避免并发问题）；③ 缓存更新通知（如Canal监听数据库binlog，自动更新缓存）；④ 最终一致性（接受短期不一致，通过定时任务同步缓存与数据库数据）。

（2）消息队列（高并发解耦、削峰填谷核心，面试必说）

高并发场景下，大量请求直接调用核心服务（如下单请求直接调用库存、支付、物流服务），会导致服务之间耦合度高、峰值请求压力集中，而消息队列的核心作用是「解耦、削峰填谷、异步通信」，将同步调用转为异步调用，分摊请求压力，提升系统高可用。2026年面试重点考察消息队列的核心原理、适用场景、主流工具、核心问题及解决方案。

• ① 消息队列核心作用（面试必背）：

• 削峰填谷：高并发峰值时（如双11下单峰值），大量请求发送到消息队列，消息队列缓存请求，核心服务按自身处理能力，从消息队列中消费请求，避免核心服务被峰值请求压垮；

• 解耦：服务之间通过消息队列通信，无需直接调用，降低服务耦合度（如下单服务无需直接调用物流服务，只需发送消息到消息队列，物流服务消费消息即可）；

• 异步通信：将同步操作转为异步操作，提升接口响应速度（如用户下单后，无需等待物流、推送消息完成，直接返回下单成功，后续异步处理）；

• 流量控制：消息队列可控制消费速度，避免消费端被大量消息压垮（如设置消费线程数、限流）；

• 最终一致性：通过消息队列的可靠性，保证跨服务操作的最终一致性（如事务消息，保证下单、扣减库存、支付的最终一致性）。

② 主流消息队列（面试必说，2026年高频）：

• RocketMQ：Alibaba开源，后捐给Apache，Java生态友好，支持事务消息、延迟消息、顺序消息、集群部署，高可用、高吞吐量，适合Java微服务高并发场景（生产首选，如电商、支付）；

• Kafka：LinkedIn开源，后捐给Apache，高吞吐量、高并发，支持分布式集群，适合大数据场景（如日志收集、数据同步），也适合高并发消息通信，但事务消息、延迟消息支持较弱；

• RabbitMQ：基于AMQP协议，开源，功能全面（支持多种交换机类型、延迟消息、死信队列），易用性高，但吞吐量低于RocketMQ、Kafka，适合中小规模、对吞吐量要求不高的场景；

• 面试延伸：RocketMQ与Kafka的区别？------ ① 吞吐量：Kafka略高于RocketMQ；② 功能：RocketMQ支持事务消息、延迟消息，Kafka支持较弱；③ 易用性：RocketMQ Java生态友好，Kafka配置复杂；④ 适用场景：RocketMQ适合Java微服务、核心业务（下单、支付），Kafka适合大数据、日志收集。

③ 消息队列核心问题（面试必说，踩坑重点）：

• 消息丢失：消息从生产者发送到消息队列、消费者消费消息的过程中，因网络异常、服务故障、配置不当，导致消息丢失；

• 解决方案（面试必说）：

• 生产者：开启消息确认机制（如RocketMQ的同步发送+消息确认、Kafka的acks=all），确保消息成功发送到消息队列；

• 消息队列：开启持久化（如RocketMQ的消息持久化到磁盘、Kafka的日志持久化），避免消息队列重启后消息丢失；

• 消费者：开启消息确认机制（如手动ACK），消费完成后再确认消息，避免消费失败导致消息丢失；同时处理消费重试，避免消息因消费异常丢失。

消息重复消费：因网络异常、消息重试、消费者故障，导致同一条消息被消费者多次消费，可能出现数据错乱（如重复扣减库存）；

• 解决方案（面试必说）：① 消费端幂等性处理（核心，如基于订单ID去重，重复消费不影响结果）；② 消息队列设置消息唯一ID，消费端根据唯一ID去重；③ 基于数据库唯一索引去重。

消息顺序性：某些场景下，消息需要按发送顺序消费（如下单→支付→发货，消息必须按此顺序消费），否则会出现业务错乱；

• 解决方案（面试必说）：① 单个队列+单个消费者（保证顺序，但吞吐量低）；② 消息分区+分区内顺序（如Kafka的分区、RocketMQ的队列，同一分区/队列的消息按顺序发送和消费，不同分区/队列可并行）；③ 全局顺序（如使用单个队列，适合对顺序要求极高、吞吐量低的场景）。

消息堆积：消费者消费速度低于生产者发送速度，导致大量消息堆积在消息队列中，占用消息队列存储空间，甚至影响消息队列性能；

• 解决方案（面试必说）：① 提升消费端性能（增加消费线程数、优化消费逻辑）；② 水平扩展消费端（部署多个消费者节点，并行消费）；③ 临时扩容消息队列分区/队列，增加消费并行度；④ 丢弃无关消息（如过期消息）；⑤ 限流生产者，控制消息发送速度。

（3）限流与降级（高并发高可用保障，面试必说）

高并发峰值时（如双11、秒杀活动），即使有缓存、消息队列，核心服务仍可能被大量请求压垮，而限流与降级的核心作用是「保护核心服务，避免系统崩溃」------ 限流是"限制请求流量"，避免超过系统处理能力；降级是"牺牲非核心服务，保障核心服务可用"，两者是高并发系统的"最后一道防线"。2026年面试重点考察限流算法、降级策略、主流工具。

① 限流核心原理与算法（面试必背）

限流（Rate Limiting）的核心原理是「控制单位时间内允许通过的请求数量」，超过限制的请求，直接拒绝、排队或降级处理，避免系统被峰值请求压垮。

• 核心限流算法（面试必说，2026年高频）：

• 固定窗口限流算法：将时间划分为固定大小的窗口（如1秒），每个窗口内允许通过固定数量的请求（如1000个），超过则拒绝；优点：原理简单，实现容易；缺点：临界问题（如窗口切换时，可能出现2倍请求量，如1秒窗口的最后100ms和下一秒的前100ms，各通过1000个请求），导致瞬时流量过载，适合对限流精度要求不高的场景（如后台管理系统接口）。

• 滑动窗口限流算法：对固定窗口进行拆分，将1秒窗口拆分为10个100ms的小窗口，每次时间滑动一个小窗口（如每100ms滑动一次），累计最近1秒内的请求量，超过限制则拒绝；优点：解决固定窗口的临界问题，限流精度更高；缺点：实现复杂度高于固定窗口，需维护小窗口的请求计数，适合对限流精度有一定要求的场景（如电商商品详情接口）。

• 漏桶算法：将请求比作水流，漏桶比作缓冲容器，请求匀速进入漏桶，漏桶以固定速度向外"漏水"（处理请求），当漏桶满了，多余的请求直接拒绝；优点：强制限制请求的处理速度，避免瞬时流量压垮服务；缺点：无法应对突发流量（即使服务空闲，也只能匀速处理请求），适合对请求处理速度有严格限制的场景（如第三方接口调用，避免触发对方限流）。

• 令牌桶算法：系统以固定速度向令牌桶中生成令牌（如每秒生成1000个令牌），请求进入时，需从桶中获取一个令牌，获取到令牌则允许处理，无令牌则拒绝或排队；优点：既能限制平均请求速率，又能应对突发流量（桶中积累的令牌可快速处理突发请求），灵活性更高；缺点：实现复杂度较高，需维护令牌桶的生成和消耗，是2026年生产环境主流限流算法（如API网关限流、电商下单接口限流）。

• 面试延伸：漏桶算法与令牌桶算法的区别？------ ① 处理突发流量：令牌桶支持，漏桶不支持；② 速率控制：漏桶控制处理速率，令牌桶控制生成速率（间接控制处理速率）；③ 灵活性：令牌桶更高，适合大多数高并发场景；漏桶更严格，适合对速率有硬性要求的场景。

② 主流限流工具（面试必说，2026年生产主流）

限流算法需结合具体工具落地，2026年面试重点考察主流限流工具的选型、用法及适用场景，无需死记API细节，重点掌握工具特性与业务匹配度。

• 本地限流工具：

• Guava RateLimiter：基于令牌桶算法实现，轻量级，易用性高，适合单个JVM进程内的限流（如单体应用接口限流）；优点：配置简单、响应快；缺点：仅支持本地限流，分布式场景下无法统一控制流量，适合单体应用或分布式节点独立限流场景。

• Sentinel 本地限流：Alibaba开源的流量控制组件，支持令牌桶、漏桶等多种限流算法，可自定义限流规则（如根据接口、IP、用户限流），支持熔断降级联动，轻量级且易用，适合Java微服务本地限流（生产主流）。

• 分布式限流工具：

• Sentinel 分布式限流：基于Sentinel Dashboard控制台，可统一配置分布式节点的限流规则，实现全链路流量控制，支持集群限流、流控效果（快速失败、Warm Up、排队等待），适合Java微服务分布式场景（2026年生产首选）。

• Redis 分布式限流：基于Redis的incr命令、Lua脚本实现（如令牌桶、滑动窗口算法），无需依赖第三方组件，灵活性高，适合多语言分布式架构；优点：无侵入性、适配多语言；缺点：需手动编写Lua脚本，维护成本略高，适合中小型分布式系统。

• API网关限流：如Spring Cloud Gateway、Zuul，结合Sentinel、Redis实现网关层统一限流，拦截外部请求，保护后端服务，适合微服务架构的入口限流（如用户请求先经过网关限流，再转发到业务服务）。

③ 降级核心原理与策略（面试必说）

降级（Degradation）的核心原理是「当系统出现高并发峰值、服务故障、资源耗尽时，牺牲非核心服务的可用性，释放系统资源，保障核心服务（如下单、支付）正常运行」，避免系统整体崩溃。降级是高并发系统的"兜底方案"，面试时需重点掌握降级触发条件、降级策略、落地方式。

• ① 降级触发条件（面试必说）：

• 高并发峰值触发：当系统QPS、并发量达到预设阈值，核心服务压力过大，触发非核心服务降级；

• 服务故障触发：当非核心服务出现异常（如超时、报错、宕机），为避免故障扩散到核心服务，触发该服务降级；

• 资源耗尽触发：当系统CPU、内存、磁盘、网络等资源耗尽，触发降级，释放资源，保障核心服务；

• 依赖服务故障触发：当核心服务依赖的第三方服务、基础服务（如缓存、数据库）故障，触发核心服务的降级兜底（如缓存故障，降级为直接返回默认数据）。

② 核心降级策略（面试必背，按优先级分类）：

• 页面降级：非核心页面（如商品评价、历史订单）降级为静态页面，或隐藏部分功能（如关闭评论、分享功能），减少服务请求；适合前端页面限流降级（如电商活动页，高并发时隐藏非核心模块）。

• 接口降级：非核心接口（如用户画像、数据统计）直接返回默认值、空值或提示信息（如"当前服务繁忙，请稍后再试"），停止调用后端业务逻辑；适合后端接口限流降级（如高并发时，用户画像接口返回默认数据）。

• 服务降级：停止非核心服务（如积分兑换、消息推送），释放服务占用的线程、内存资源，优先保障核心服务；适合微服务架构（如双11时，停止积分兑换服务，保障下单、支付服务）。

• 熔断降级：当服务出现连续报错、超时（如接口超时率超过50%），自动触发熔断，暂时停止该服务的调用，一段时间后尝试恢复，避免故障扩散；适合核心服务依赖的非核心服务（如支付服务依赖的短信通知服务，熔断后不影响支付）。

• 兜底降级：核心服务出现故障时，调用兜底逻辑（如缓存故障，降级为查询数据库；数据库故障，降级为返回缓存旧数据），避免核心服务不可用；适合核心服务的最后兜底（如电商下单，库存查询失败，降级为返回"库存紧张"）。

③ 降级主流工具与落地方式（面试必说）：

• 主流工具：Sentinel（支持熔断降级、限流降级联动，可配置降级规则、兜底逻辑，Java生态友好，生产主流）、Resilience4j（轻量级，支持熔断、降级、限流，适合Spring Boot微服务）、Hystrix（Netflix开源，老牌熔断降级组件，功能全面，但已停止维护，适合老项目）。

• 落地方式（面试重点）：

• 配置化降级：通过控制台（如Sentinel Dashboard）配置降级规则（触发条件、降级策略、恢复时间），无需修改代码，动态生效，适合生产环境灵活调整；

• 编码式降级：通过注解（如@SentinelResource、@HystrixCommand）定义兜底方法，当服务触发降级时，自动调用兜底方法，适合固定兜底逻辑的场景；

• 网关层降级：在API网关层配置降级规则，拦截非核心请求，直接返回降级响应，减少后端服务压力，适合微服务入口降级。

面试延伸：限流与降级的区别与关联？------ ① 区别：限流是"限制请求流量"，避免超过系统处理能力（事前预防）；降级是"牺牲非核心服务"，保障核心服务可用（事后兜底）；② 关联：高并发场景下，限流与降级通常联动使用（如限流拒绝部分请求，降级非核心服务，共同保护核心服务），是高可用的双重保障。

二、实践落地（聚焦2026年生产场景，面试落地能力体现）

底层理论的核心价值的是落地到生产场景，面试时，面试官最看重的是「理论结合实践」的能力------ 能否将线程、锁、线程池、缓存、消息队列、限流降级等知识，运用到实际高并发场景中，解决真实业务问题。本部分将围绕2026年生产高频高并发场景，拆解落地步骤、核心选型、代码示例（简化核心逻辑，贴合面试表述）、踩坑点，让你既能说清理论，又能讲透落地。

1. 实践落地核心原则（面试必说）

• ① 贴合业务场景：所有技术选型、方案设计，都需围绕业务需求（如高并发场景的QPS、数据一致性要求、响应时间要求），不盲目追求"高端技术"；

• ② 兼顾性能与可用性：落地方案需在性能（响应速度、吞吐量）和可用性（稳定性、容错性）之间找到平衡，避免为了性能牺牲核心可用性；

• ③ 简化复杂度：优先选择成熟、易用、维护成本低的技术方案，避免过度设计（如中小型系统，无需搭建复杂的分布式集群）；

• ④ 可监控、可扩展：落地方案需具备监控能力（如监控QPS、响应时间、错误率），便于问题排查；同时预留扩展空间（如线程池参数可动态调整、缓存可集群扩容）；

• ⑤ 容错兜底：所有高并发落地方案，都需有容错兜底逻辑（如缓存故障降级、服务故障熔断、限流拒绝提示），避免系统整体崩溃。

2. 2026年高频高并发场景实践落地（面试重中之重）

以下场景均为2026年Java高级/架构岗面试高频场景，每个场景拆解「业务需求、核心痛点、落地方案、选型建议、代码示例、踩坑点」，贴合生产实际，避免纸上谈兵。

（1）场景一：电商商品详情页（高并发读、低并发写，核心场景）

业务需求：商品详情页（如手机、服装详情），日均访问量1000万+，峰值QPS 10万+，商品信息（标题、价格、规格）修改频率低（每天几次），需保证页面响应时间≤100ms，高可用（可用性99.99%）。

• ① 核心痛点：高频读请求，若直接查询数据库，会导致数据库压力激增，响应超时；商品信息修改后，需保证缓存与数据库数据一致；缓存故障时，需避免服务不可用。

• ② 落地方案（多级缓存+缓存优化，核心）：

• 第一步：多级缓存设计（本地缓存→Redis分布式缓存→数据库），兼顾访问速度和数据一致性；

• 第二步：缓存预热：商品信息修改后，主动更新Redis缓存和本地缓存，避免缓存穿透；新品上架时，批量将商品信息写入缓存，避免首次访问穿透到数据库；

• 第三步：缓存优化：商品详情页静态化（如HTML静态页），通过CDN加速，减少后端服务请求；缓存过期时间随机化（如1小时±10分钟），避免缓存雪崩；

• 第四步：容错兜底：Redis缓存故障时，降级为本地缓存兜底；本地缓存无数据时，通过互斥锁控制单个请求查询数据库，避免缓存击穿。

③ 技术选型：

• 本地缓存：Caffeine（高性能，支持自动过期，生产首选）；

• 分布式缓存：Redis Cluster（集群部署，避免单点故障，支持Hash数据结构存储商品信息）；

• 静态化：Vue+Nginx静态化，CDN加速（如阿里云CDN）；

• 数据库：MySQL（主从复制，读库分担查询压力）。

④ 核心代码示例（简化，面试表述重点）：

// 商品详情查询核心逻辑（多级缓存）
public ProductDetail getProductDetail(Long productId) {
    // 1. 先查本地缓存（Caffeine）
    ProductDetail localDetail = caffeineCache.getIfPresent(productId);
    if (localDetail != null) {
        return localDetail;
    }
    // 2. 本地缓存无，查Redis缓存
    String redisKey = "product:detail:" + productId;
    String redisValue = redisTemplate.opsForValue().get(redisKey);
    if (redisValue != null) {
        ProductDetail redisDetail = JSON.parseObject(redisValue, ProductDetail.class);
        // 写入本地缓存，设置过期时间
        caffeineCache.put(productId, redisDetail, Duration.ofMinutes(30));
        return redisDetail;
    }
    // 3. Redis无，查数据库（互斥锁控制，避免缓存击穿）
    String lockKey = "product:lock:" + productId;
    try {
        boolean lock = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(5));
        if (lock) {
            // 获得锁，查询数据库
            ProductDetail dbDetail = productMapper.selectById(productId);
            if (dbDetail != null) {
                // 写入Redis，设置随机过期时间（1小时±10分钟）
                int expire = 3600 + new Random().nextInt(1200) - 600;
                redisTemplate.opsForValue().set(redisKey, JSON.toJSONString(dbDetail), expire, TimeUnit.SECONDS);
                // 写入本地缓存
                caffeineCache.put(productId, dbDetail, Duration.ofMinutes(30));
                return dbDetail;
            } else {
                // 数据库无数据，缓存空值（短期过期），避免缓存穿透
                redisTemplate.opsForValue().set(redisKey, "", 60, TimeUnit.SECONDS);
                return null;
            }
        } else {
            // 未获得锁，休眠100ms后重试
            Thread.sleep(100);
            return getProductDetail(productId);
        }
    } catch (Exception e) {
        log.error("查询商品详情异常", e);
        // 异常降级，返回默认数据（兜底）
        return getDefaultProductDetail();
    } finally {
        // 释放锁
        redisTemplate.delete(lockKey);
    }
}

// 商品信息更新逻辑（保证缓存一致性）
public void updateProductDetail(ProductDetail productDetail) {
    // 1. 先更新数据库
    productMapper.updateById(productDetail);
    // 2. 再删除Redis缓存（避免缓存脏写）
    String redisKey = "product:detail:" + productDetail.getId();
    redisTemplate.delete(redisKey);
    // 3. 延迟双删（避免并发问题）
    CompletableFuture.runAsync(() -> {
        try {
            Thread.sleep(500);
            redisTemplate.delete(redisKey);
        } catch (InterruptedException e) {
            log.error("延迟删除Redis缓存异常", e);
        }
    });
    // 4. 清除本地缓存
    caffeineCache.invalidate(productDetail.getId());
}

⑤ 踩坑点（面试必说）：

• 坑1：缓存与数据库一致性问题------ 避免"先更缓存、再更数据库"，否则会出现并发脏写（如线程A更新缓存，线程B更新数据库，线程A的缓存覆盖线程B的数据库数据）；解决方案：先更数据库，再删缓存+延迟双删。

• 坑2：缓存击穿------ 热门商品缓存过期时，大量请求穿透到数据库；解决方案：热点商品永不过期，或通过互斥锁控制单个请求查询数据库。

• 坑3：本地缓存数据不一致------ 分布式节点的本地缓存，无法及时同步更新；解决方案：商品更新时，通过消息队列通知所有节点清除本地缓存，或设置本地缓存短期过期（如30分钟）。

（2）场景二：电商下单接口（高并发写、数据一致性要求高，核心场景）

业务需求：电商下单接口（如下单购买商品），峰值QPS 5万+，每秒订单量500+，需保证订单数据一致性（下单成功→库存扣减成功、余额扣减成功），响应时间≤300ms，避免超卖、少卖，高可用。

• ① 核心痛点：高并发写请求，容易出现超卖（库存为0仍能下单）、少卖（下单成功但库存未扣减）；跨服务调用（下单→库存→支付），需保证最终一致性；峰值请求压力大，需避免服务被压垮。

• ② 落地方案（消息队列削峰+分布式锁+事务消息，核心）：

• 第一步：消息队列削峰填谷：下单请求发送到RocketMQ，下单服务异步消费消息，避免峰值请求直接压垮核心服务；

• 第二步：分布式锁控制库存：使用Redis分布式锁，保证同一商品的库存扣减互斥，避免超卖；

• 第三步：事务一致性保障：使用RocketMQ事务消息，保证"下单成功"与"库存扣减、支付扣减"的最终一致性（下单服务发送事务消息，库存、支付服务消费消息，失败则回滚）；

• 第四步：限流降级：下单接口通过Sentinel限流，峰值时拒绝部分请求，返回"当前下单人数过多，请稍后再试"；非核心下单功能（如优惠券叠加）降级，提升核心下单速度。

③ 技术选型：

• 消息队列：RocketMQ（支持事务消息、顺序消息，Java生态友好，生产首选）；

• 分布式锁：Redis分布式锁（基于Lua脚本实现，保证原子性）；

• 限流工具：Sentinel（网关层+服务层双重限流）；

• 数据库：MySQL（分库分表，订单表按用户ID分表，库存表按商品ID分表，分担写入压力）；

• 缓存：Redis（存储商品库存，提升库存查询速度）。

④ 核心代码示例（简化，面试表述重点）：

// 下单核心逻辑（消息队列异步处理+分布式锁）
@Transactional
public String createOrder(OrderRequest request) {
    Long userId = request.getUserId();
    Long productId = request.getProductId();
    Integer quantity = request.getQuantity();
    
    // 1. 校验用户、商品合法性（简化）
    checkUserAndProduct(userId, productId);
    
    // 2. 生成订单号（全局唯一）
    String orderNo = IdUtil.getSnowflakeNextIdStr();
    
    // 3. 发送事务消息到RocketMQ，异步处理库存扣减、下单
    try {
        // 构建事务消息
        Message<String> message = MessageBuilder.withPayload(JSON.toJSONString(request))
                .setTopic("order_topic")
                .setTags("create_order")
                .setKey(orderNo)
                .build();
        // 发送事务消息，返回发送结果
        TransactionSendResult result = rocketMQTemplate.sendMessageInTransaction(
                "order_producer_group", message, orderNo);
        if (result.getSendStatus() != SendStatus.SEND_OK) {
            throw new RuntimeException("下单失败，请稍后再试");
        }
        return orderNo;
    } catch (Exception e) {
        log.error("创建订单异常", e);
        throw new RuntimeException("下单失败，请稍后再试");
    }
}

// RocketMQ事务消息监听器（保证订单与库存一致性）
@RocketMQTransactionListener(txProducerGroup = "order_producer_group")
public class OrderTransactionListener implements RocketMQLocalTransactionListener {
    // 本地事务执行（创建订单记录）
    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message<?> msg, Object arg) {
        String orderNo = (String) arg;
        OrderRequest request = JSON.parseObject(new String((byte[]) msg.getPayload()), OrderRequest.class);
        try {
            // 创建订单记录（数据库），状态为"待支付"
            Order order = buildOrder(request, orderNo, "WAIT_PAY");
            orderMapper.insert(order);
            // 本地事务执行成功，返回COMMIT
            return RocketMQLocalTransactionState.COMMIT;
        } catch (Exception e) {
            log.error("本地事务执行失败", e);
            // 本地事务执行失败，返回ROLLBACK
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }

    // 事务回查（解决消息丢失、本地事务执行结果未知问题）
    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message<?> msg) {
        String orderNo = msg.getKeys();
        Order order = orderMapper.selectByOrderNo(orderNo);
        if (order == null) {
            // 订单不存在，回滚
            return RocketMQLocalTransactionState.ROLLBACK;
        }
        // 订单存在，提交
        return RocketMQLocalTransactionState.COMMIT;
    }
}

// 库存扣减逻辑（分布式锁控制，避免超卖）
public boolean deductStock(Long productId, Integer quantity) {
    String lockKey = "stock:lock:" + productId;
    String lockValue = UUID.randomUUID().toString();
    try {
        // 获得分布式锁（设置过期时间，避免死锁）
        boolean lock = redisTemplate.opsForValue().setIfAbsent(lockKey, lockValue, 3, TimeUnit.SECONDS);
        if (!lock) {
            // 未获得锁，返回失败（重试）
            return false;
        }
        // 1. 查询Redis库存（先查缓存，再查数据库）
        String stockKey = "product:stock:" + productId;
        Integer stock = (Integer) redisTemplate.opsForValue().get(stockKey);
        if (stock == null) {
            // 缓存无数据，查数据库
            Product product = productMapper.selectById(productId);
            stock = product.getStock();
            redisTemplate.opsForValue().set(stockKey, stock);
        }
        // 2. 校验库存
        if (stock < quantity) {
            // 库存不足，返回失败
            return false;
        }
        // 3. 扣减库存（Redis+数据库，保证一致性）
        // 先扣Redis库存（原子操作）
        redisTemplate.opsForValue().decrement(stockKey, quantity);
        // 再扣数据库库存（异步更新，通过消息队列）
        rocketMQTemplate.convertAndSend("stock_topic", new StockDeductDTO(productId, quantity));
        return true;
    } catch (Exception e) {
        log.error("扣减库存异常", e);
        return false;
    } finally {
        // 释放锁（Lua脚本，保证原子性，避免释放别人的锁）
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        redisTemplate.execute(new DefaultRedisScript<Integer>(script, Integer.class), 
                Collections.singletonList(lockKey), lockValue);
    }
}

⑤ 踩坑点（面试必说）：

• 坑1：超卖问题------ 分布式场景下，多个节点同时扣减库存，容易出现超卖；解决方案：使用Redis分布式锁（Lua脚本保证原子性），或数据库乐观锁（版本号机制），避免并发扣减。

• 坑2：订单与库存一致性问题------ 下单成功但库存扣减失败，或库存扣减成功但订单创建失败；解决方案：使用事务消息，保证两者最终一致性，结合定时任务回查，处理异常订单。

• 坑3：消息堆积------ 峰值时下单消息过多，消费速度跟不上，导致消息堆积；解决方案：水平扩展消费端节点，增加消费线程数，优化库存扣减逻辑，提升消费速度。

• 坑4：分布式锁死锁------ 锁未释放（如服务宕机），导致后续请求无法获得锁；解决方案：设置锁过期时间，结合Lua脚本释放锁，定时清理过期锁。

（3）场景三：全局计数器（高并发原子操作，常见场景）

业务需求：电商活动页面的访问计数器、商品点赞数、评论数，峰值QPS 1万+，需保证计数准确（无重复计数、无漏计数），支持高并发写入，响应时间≤50ms。

• ① 核心痛点：高并发原子自增/自减，若使用Java原子类（如AtomicInteger），分布式场景下数据不一致；若直接操作数据库，性能低下，无法支撑高并发。

• ② 落地方案（Redis原子操作+定时持久化，核心）：

• 第一步：使用Redis的incr/decr命令，实现原子自增/自减（Redis单线程，保证原子性），支撑高并发写入；

• 第二步：定时持久化：将Redis中的计数，定时同步到数据库（如每1分钟同步一次），保证数据持久化，避免Redis故障导致计数丢失；

• 第三步：容错兜底：Redis故障时，降级为本地原子类临时计数，Redis恢复后，同步本地计数到Redis，避免计数丢失。

③ 技术选型：Redis（单机或集群，支持incr/decr原子操作）、Java原子类（AtomicLong，本地兜底）、MySQL（持久化计数）。

④ 核心代码示例（简化，面试表述重点）：

// 全局计数器核心逻辑（Redis原子操作+本地兜底）
public Long incrementCount(String countKey) {
    try {
        // 1. 先尝试使用Redis原子自增
        return redisTemplate.opsForValue().increment(countKey, 1);
    } catch (Exception e) {
        log.error("Redis计数异常，降级为本地计数", e);
        // 2. Redis故障，降级为本地原子类计数（本地缓存，key对应countKey）
        AtomicLong localCount = localCountMap.computeIfAbsent(countKey, k -> new AtomicLong(0));
        return localCount.incrementAndGet();
    }
}

// 定时同步Redis计数到数据库（每分钟执行一次）
@Scheduled(cron = "0 0/1 * * * ?")
public void syncCountToDb() {
    // 1. 获取所有计数key
    Set<String> countKeys = redisTemplate.keys("count:*");
    if (CollectionUtils.isEmpty(countKeys)) {
        return;
    }
    // 2. 批量查询Redis计数，同步到数据库
    List&lt;CountDTO&gt; countList = new ArrayList<>();
    for (String key : countKeys) {
        Long count = (Long) redisTemplate.opsForValue().get(key);
        if (count == null) {
            continue;
        }
        // 解析key，获取计数类型（如访问量、点赞数）和关联ID（如商品ID）
        String[] keyArr = key.split(":");
        String countType = keyArr[1];
        Long relatedId = Long.parseLong(keyArr[2]);
        countList.add(new CountDTO(countType, relatedId, count));
    }
    // 批量更新数据库（简化）
    if (!CollectionUtils.isEmpty(countList)) {
        countMapper.batchUpdate(countList);
    }
    
    // 3. 同步本地兜底计数到Redis（Redis恢复后）
    if (!localCountMap.isEmpty()) {
        localCountMap.forEach((key, count) -> {
            redisTemplate.opsForValue().set(key, count);
        });
        // 清空本地计数
        localCountMap.clear();
    }
}

⑤ 踩坑点（面试必说）：

• 坑1：计数丢失------ Redis故障时，未做本地兜底，导致计数丢失；解决方案：结合本地原子类兜底，Redis恢复后同步本地计数。

• 坑2：数据不一致------ 定时同步数据库时，Redis计数已更新，但数据库未同步，导致查询数据库时计数不准确；解决方案：查询计数时，优先查询Redis，数据库仅作为持久化存储，不用于实时查询。

• 坑3：Redis集群原子性问题------ Redis集群模式下，incr命令可能跨节点，导致原子性无法保证；解决方案：使用Redis哈希槽，将同一计数key路由到同一节点，或使用Redis单机（适合计数场景，压力可控）。

（4）场景四：微服务接口限流降级（高并发入口保护，常见场景）

业务需求：微服务架构（如用户服务、订单服务、商品服务），外部请求通过Spring Cloud Gateway进入，峰值QPS 8万+，需保护核心接口（如下单、用户登录），避免非核心接口占用过多资源，服务故障时快速熔断降级。

• ① 核心痛点：外部请求流量不可控，峰值时可能压垮核心服务；微服务之间依赖复杂，一个服务故障可能扩散到整个集群；需灵活配置限流降级规则，动态调整。

• ② 落地方案（网关层限流+服务层限流+熔断降级，核心）：

• 第一步：网关层限流：Spring Cloud Gateway结合Sentinel，实现入口限流，拦截无效请求、过量请求，保护后端服务；

• 第二步：服务层限流：每个微服务通过Sentinel，对核心接口单独限流（如用户登录接口QPS限制5000），非核心接口限流阈值降低；

• 第三步：熔断降级：微服务之间调用（如订单服务调用库存服务），通过Sentinel配置熔断规则，当库存服务超时率、错误率超过阈值，自动熔断，调用兜底逻辑；

• 第四步：动态配置：通过Sentinel Dashboard控制台，动态配置限流、熔断规则，无需重启服务，适配流量变化。

③ 技术选型：Spring Cloud Gateway（网关）、Sentinel（限流熔断，控制台动态配置）、Nacos（配置中心，存储限流规则）。

④ 核心配置示例（简化，面试表述重点）：

# 1. Spring Cloud Gateway + Sentinel 网关限流配置
spring:
  cloud:
    sentinel:
      transport:
        dashboard: 127.0.0.1:8080 # Sentinel控制台地址
        port: 8719
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/order/**
          filters:
            - name: Sentinel # 开启Sentinel限流
              args:
                resource: order_service_route # 限流资源名
                limitApp: default # 限制所有来源
                grade: 1 # 限流粒度：QPS
                count: 5000 # 限流阈值：5000 QPS
                controlBehavior: 0 # 流控效果：快速失败

# 2. 服务层 Sentinel 限流熔断配置（application.yml）
spring:
  cloud:
    sentinel:
      datasource:
        ds1:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: sentinel-order-service
            groupId: DEFAULT_GROUP
            rule-type: flow # 限流规则
        ds2:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: sentinel-order-service
            groupId: DEFAULT_GROUP
            rule-type: degrade # 熔断规则

# 3. Nacos中 Sentinel 限流规则配置（JSON格式）
[
  {
    "resource": "createOrder", # 限流资源（接口方法名）
    "grade": 1, # QPS限流
    "count": 3000, # 阈值3000 QPS
    "clusterMode": false,
    "controlBehavior": 0,
    "limitApp": "default"
  }
]

# 4. Nacos中 Sentinel 熔断规则配置（JSON格式）
[
  {
    "resource": "deductStock", # 熔断资源（调用的库存接口）
    "grade": 0, # 按错误率熔断
    "count": 0.5, # 错误率阈值50%
    "timeWindow": 10, # 熔断时间窗口10秒
    "minRequestAmount": 100, # 最小请求数100（触发熔断的最小请求量）
    "statIntervalMs": 1000 # 统计时间窗口1秒
  }
]

// 服务层接口限流+熔断兜底示例
@RestController
@RequestMapping("/order")
public class OrderController {

    @Autowired
    private StockFeignClient stockFeignClient;

    // 下单接口，配置Sentinel限流，资源名：createOrder
    @SentinelResource(
            value = "createOrder",
            blockHandler = "createOrderBlockHandler", // 限流兜底方法
            fallback = "createOrderFallback" // 熔断/异常兜底方法
    )
    @PostMapping("/create")
    public Result<String> createOrder(@RequestBody OrderRequest request) {
        // 调用库存服务扣减库存（可能触发熔断）
        boolean deductSuccess = stockFeignClient.deductStock(request.getProductId(), request.getQuantity());
        if (!deductSuccess) {
            return Result.fail("下单失败，库存不足");
        }
        // 创建订单（简化）
        String orderNo = orderService.createOrder(request);
        return Result.success(orderNo);
    }

    // 限流兜底方法（参数、返回值需与原方法一致，额外增加BlockException参数）
    public Result<String> createOrderBlockHandler(OrderRequest request, BlockException e) {
        log.error("下单接口限流，请求参数：{}", request, e);
        return Result.fail("当前下单人数过多，请稍后再试");
    }

    // 熔断/异常兜底方法（参数、返回值需与原方法一致，额外增加Throwable参数）
    public Result<String> createOrderFallback(OrderRequest request, Throwable e) {
        log.error("下单接口异常，请求参数：{}", request, e);
        return Result.fail("系统繁忙，请稍后再试");
    }
}

⑤ 踩坑点（面试必说）：

• 坑1：限流规则配置不当------ 限流阈值设置过高，无法保护服务；设置过低，影响正常用户请求；解决方案：结合历史流量数据，动态调整限流阈值，通过Sentinel控制台监控流量，实时优化。

• 坑2：熔断时间窗口设置不当------ 熔断时间窗口过短，服务未恢复就重新调用，导致反复熔断；过长，影响用户体验；解决方案：根据服务恢复速度，设置合理的时间窗口（如10-30秒），结合定时任务监控服务状态，提前恢复。

• 坑3：兜底逻辑不完善------ 限流、熔断后，未返回友好提示，或兜底逻辑本身报错；解决方案：兜底逻辑尽量简单，避免依赖其他服务，返回明确的用户提示（如"当前繁忙，请稍后再试"）。

3. 实践落地通用踩坑总结（面试必背）

结合以上所有场景，总结2026年生产环境高并发落地的通用踩坑点，面试时主动提及，可大幅加分，体现落地经验：

• ① 数据一致性踩坑：缓存与数据库、消息队列与业务服务、分布式节点之间的数据一致性，是高并发落地的核心难点，避免"先更缓存、再更数据库""同步调用跨服务"，优先选择最终一致性方案（如事务消息、延迟双删）。

• ② 锁使用踩坑：本地锁在分布式场景下无效，分布式锁未设置过期时间导致死锁，锁粒度太大导致性能低下；解决方案：分布式场景用Redis/ZK分布式锁，设置合理过期时间，减小锁粒度（如按商品ID加锁，而非全局锁）。

• ③ 线程池使用踩坑：使用Executors创建线程池导致OOM、线程泄露，核心参数配置不合理（如核心线程数过多、队列无界）；解决方案：用ThreadPoolExecutor手动创建，根据业务场景配置核心参数，使用有界队列，设置线程工厂和拒绝策略。

• ④ 缓存使用踩坑：缓存穿透、击穿、雪崩未处理，缓存过期时间设置不合理，缓存与数据库一致性未保障；解决方案：针对性处理三大缓存问题，缓存过期时间随机化，优先"先更数据库、再删缓存"。

• ⑤ 监控运维踩坑：未监控高并发接口的QPS、响应时间、错误率，出现问题无法快速排查；解决方案：搭建监控体系（如Prometheus+Grafana），监控核心指标，设置告警（如错误率超过1%告警），定期排查问题。

三、最佳实践（2026年面试高频，架构优化+面试加分）

最佳实践是在底层理论、实践落地的基础上，结合2026年行业趋势，总结的高并发系统设计、优化、面试应答的核心技巧------ 不仅能帮助你落地高并发系统，更能让你在面试中脱颖而出，体现架构思维和落地能力。本部分分为「架构设计最佳实践、性能优化最佳实践、面试应答最佳实践」三部分，聚焦高频考点和生产痛点。

1. 架构设计最佳实践（2026年生产主流，面试必说）

高并发系统的架构设计，核心是"拆分、冗余、兜底"，避免单体系统的性能瓶颈，保证系统的高可用、可扩展，以下是2026年生产主流的架构设计最佳实践：

• ① 分层架构设计（基础）：严格遵循"前端→网关→业务服务→数据层"分层，每层职责单一，避免跨层调用；

• • 前端层：静态化、CDN加速，减少后端请求；
• • 网关层：统一入口，负责限流、降级、路由、鉴权，保护后端服务；
• • 业务服务层：微服务拆分（按业务域拆分，如下单服务、商品服务、用户服务），服务之间通过RPC/消息队列通信，避免耦合；
• • 数据层：缓存（本地+分布式）、数据库（分库分表）、消息队列，分担数据存储和访问压力。

② 微服务拆分最佳实践（面试重点）：

• 拆分原则：单一职责（一个服务只做一件事）、高内聚低耦合（服务内部逻辑紧密，服务之间依赖松散）、粒度适中（避免过细导致服务过多，维护复杂；避免过粗导致单体瓶颈）；

• 反例：将下单、库存、支付逻辑放在一个服务中，导致服务庞大，高并发时性能瓶颈明显；

• 正例：下单服务（负责订单创建、查询）、库存服务（负责库存扣减、查询）、支付服务（负责支付处理），服务之间通过消息队列/Feign通信，独立扩展。

③ 冗余设计（高可用核心）：

• 服务冗余：每个微服务部署多个节点（如2-3个节点），避免单点故障，通过负载均衡（如Nginx、Ribbon）分发请求；

• 数据冗余：缓存集群（Redis Cluster）、数据库主从复制（一主多从）、异地多活（核心业务，如支付，部署多个地域的节点），避免数据丢失；

• 组件冗余：消息队列集群（RocketMQ Cluster）、网关集群，避免组件单点故障导致整个系统不可用。

④ 兜底设计（高可用最后一道防线）：

• 每层都需有兜底逻辑：网关层限流兜底、服务层熔断降级兜底、数据层缓存故障兜底；

• 核心服务兜底优先级高于非核心服务：如下单服务兜底逻辑优先保障"订单创建"，可牺牲"优惠券叠加""消息推送"等非核心功能；

• 异常兜底：所有接口、方法都需捕获异常，避免空指针、超时等异常导致服务崩溃，返回友好提示和默认数据。

⑤ 可扩展设计（应对流量增长）：

• 水平扩展优先于垂直扩展：通过增加节点（如服务节点、Redis节点、数据库从库）扩展性能，而非升级单节点硬件（垂直扩展）；

• 无状态设计：服务设计为无状态（如不存储用户会话、本地缓存仅作为兜底），便于水平扩展（新增节点即可分担流量）；

• 配置中心：使用Nacos、Apollo等配置中心，动态配置限流规则、线程池参数、缓存过期时间，无需重启服务，适配流量变化。

2. 性能优化最佳实践（2026年高频，面试必说）

高并发系统的性能优化，核心是"减少IO开销、减少锁竞争、提升并行度"，以下是生产环境中最常用、最有效的性能优化技巧，面试时需结合场景说明，体现优化经验：

（1）Java并发基础优化（底层优化）

• ① 线程池优化：根据业务场景合理配置核心参数，避免使用Executors；核心线程数=CPU核心数±1（CPU密集型，如计算），核心线程数=CPU核心数*2（IO密集型，如数据库查询、RPC调用）；使用有界队列，设置合理的拒绝策略；

• ② 锁优化：减小锁粒度（如按商品ID加锁，而非全局锁）、使用读写锁（读多写少场景）、避免锁嵌套（防止死锁）、优先使用乐观锁（并发冲突少场景）；JDK 1.8后，synchronized与Lock性能相当，简单场景用synchronized，复杂场景用Lock；

• ③ 原子类优化：并发计数、简单共享变量修改，优先使用Atomic系列原子类（如AtomicInteger、AtomicLong），避免使用锁，提升性能；复杂原子操作，使用CAS+自旋，或分布式锁。

（2）缓存优化（性能提升核心）

• ① 多级缓存优化：本地缓存→分布式缓存→数据库，优先从本地缓存获取数据，减少网络开销；热点数据永不过期，非热点数据随机过期时间；

• ② 缓存命中率优化：缓存高频访问数据，避免缓存低频数据（浪费内存）；缓存空值、使用布隆过滤器，避免缓存穿透；热点数据缓存预热，提升缓存命中率；

• ③ Redis优化：使用合适的数据结构（如Hash存储商品信息、ZSet存储排行榜），避免大key（如单个key存储10万+数据），导致Redis阻塞；Redis集群分片，分担存储和访问压力；开启持久化（AOF+RDB混合持久化），避免数据丢失。

（3）数据库优化（高并发写核心）

• ① 分库分表：高并发写场景（如下单），订单表、库存表按用户ID/商品ID分表，分担写入压力；分库分表工具推荐Sharding-JDBC（轻量级，无侵入）；

• ② 索引优化：给高频查询字段（如商品ID、用户ID、订单号）建立索引，避免全表扫描；避免过度索引（索引会增加写入开销）；联合索引遵循"最左前缀原则"；

• ③ 读写分离：数据库主从复制，主库负责写入，从库负责查询，分担查询压力；读库可部署多个，通过负载均衡分发查询请求；

• ④ 批量操作：高并发写入场景（如批量下单、批量更新），使用批量插入/更新SQL，避免单条操作（减少数据库连接开销）；

• ⑤ 避免长事务：长事务会占用数据库连接，导致连接耗尽，影响高并发写入；拆分长事务为短事务，减少事务执行时间。

（4）接口优化（响应速度提升）

• ① 异步化：将同步操作转为异步操作（如下单后，异步处理消息推送、积分增加），使用CompletableFuture、消息队列，提升接口响应速度；

• ② 批量查询：避免循环查询数据库/RPC（如循环查询多个商品信息），改为批量查询，减少IO次数；

• ③ 接口合并：将多个关联接口（如下单接口+用户信息接口+商品信息接口）合并为一个接口，减少前端请求次数，提升用户体验；

• ④ 压缩传输：接口请求/响应数据压缩（如Gzip压缩），减少网络传输数据量，提升响应速度；

• ⑤ 避免重复计算：将高频重复计算的结果（如商品总价、优惠金额）缓存起来，避免每次请求都重新计算。

3. 面试应答最佳实践（2026年面试加分，核心技巧）

Java高级/架构岗面试中，高并发模块的应答，核心是"先讲理论、再讲落地、最后讲优化"，避免死记硬背，结合生产案例，体现落地能力和架构思维。以下是面试应答的核心技巧和高频问题应答模板：

（1）应答核心逻辑（万能模板）

面试官问任何高并发相关问题（如"如何设计电商下单接口？""如何解决缓存雪崩？"），都可按以下逻辑应答，条理清晰，体现专业性：

1. 核心定位：先明确问题的核心痛点（如下单接口的核心痛点是高并发写、数据一致性、超卖）；

2. 理论支撑：简要说明相关底层理论（如解决超卖需用分布式锁，底层是Redis原子操作+Lua脚本）；

3. 落地方案：结合生产场景，拆解落地步骤、技术选型、核心代码逻辑（简化，重点说关键步骤）；

4. 踩坑点：主动提及落地过程中可能遇到的问题，以及解决方案（体现落地经验）；

5. 优化方向：结合最佳实践，说明如何进一步优化（如分库分表提升写入性能、多级缓存提升响应速度）。

（2）高频面试题应答模板（2026年重点）

模板1：如何解决缓存雪崩？（必问）

应答：缓存雪崩的核心痛点是大量缓存同时过期，或缓存集群故障，导致所有请求穿透到数据库，数据库崩溃。解决思路从"预防+兜底"两方面入手：① 预防：缓存过期时间随机化（如1小时±10分钟），避免大量缓存同时过期；缓存集群部署（Redis Cluster），避免单点故障；热点数据永不过期，或定时续期；② 兜底：多级缓存（本地缓存兜底），即使分布式缓存故障，本地缓存