Java后端面试高频考点：Redis/MySQL/并发/算法/数据结构五大模块精讲-育师

简介：这是一份专为Java后端及全栈开发者面试冲刺打造的「八股文」高频题集，覆盖Redis、MySQL、算法、多线程、数据结构等核心考点，直击互联网大厂技术面常见陷阱与深度追问。资源以1个25.8MB的PDF文件呈现，内容结构清晰、分类明确，包含B/S与C/S架构辨析、JDK/JRE区别、OOP四大特征、类与对象关系、Java八大基本类型及包装类、instanceof原理、自动拆装箱机制、字符类型转换规则、集合底层实现要点等近30组高频问答，每题均附简明结论与关键细节说明。已有2510人学习下载，适合应届生系统梳理基础、转行者快速补漏、在职工程师临阵复盘——不堆砌概念，重逻辑闭环；不替代实战，但夯实表达底气，助你在技术对话中精准输出、建立专业可信度。

1. 八股文不是玄学，是面试通关的「标准协议栈」：Redis/MySQL/算法/线程/数据结构五大模块占Java后端岗技术面72%分值

你刷了300道题，面试官只问了5个——但那5个，全在你漏掉的20%高频子集里。这不是运气问题，是考点分布严重不均：某大厂近一年Java后端终面技术题库抽样显示，Redis（18%）、MySQL（19%）、并发与线程（15%）、数据结构与算法（12%）、JVM与基础（8%）五块加起来占全部技术问题的72%；而剩下28%分散在Spring源码、分布式事务、消息队列等深度场景中——这些题往往出现在三面或总监面，且常以“你刚才说的XX，能不能结合我们业务场景讲讲？”方式带出，本质仍是前五大模块的组合变形。换句话说：没吃透这五大模块，连二面技术关都过不了；吃透了，哪怕只覆盖其中80%的真题变体，也能稳进终面。这份八股文资源不是让你背答案，而是帮你把散落的考点织成一张可检索、可推演、可速查的网——比如看到“缓存穿透”，立刻能联想到Redis的布隆过滤器实现、MySQL的空值缓存策略、线程安全的双重检查锁加载、以及HashMap在高并发下的扩容死链风险；这种跨模块联动能力，才是面试官真正想验证的底层思维。适合谁？校招应届生（基础不牢但时间充裕）、社招1-3年工程师（项目经验有但理论断层）、转行者（需快速建立技术坐标系）——只要你的目标是拿下下一份Offer，它就不是“可选项”，而是“启动器”。

1.1 为什么“背八股”比“看源码”更优先？

很多同学陷入一个认知陷阱：觉得“源码才是硬核，八股都是套路”。但现实是残酷的——面试官只有20分钟评估你是否值得花2小时深聊。这20分钟里，他必须用最小成本验证三件事：知识广度是否达标（能否覆盖技术栈主干）、概念边界是否清晰（能否区分相似机制的本质差异）、错误归因是否准确（遇到问题能否定位到真实根因）。而这三点，恰恰是八股文最擅长训练的。比如问“HashMap为什么线程不安全”，如果你只答“因为put时可能产生环形链表”，面试官会追问：“环形链表在什么JDK版本出现？JDK8之后呢？ConcurrentHashMap怎么解决的？CAS和synchronized哪个开销大？”——这些问题的答案，全在八股文的纵向对比表里。反观源码，你花一周啃完HashMap的resize逻辑，却可能答不出“为什么ConcurrentHashMap的size()方法要遍历所有Segment？”这种高频题。这不是贬低源码价值，而是强调：八股文是面试的“协议栈”，源码是上线后的“调试器”；协议栈不通，连握手都失败，调试器再强也无从下手。

1.2 这份资源的“非对称优势”在哪？

市面上八股文资料要么太浅（只列问题+答案），要么太深（堆砌源码+汇编）。这份资源卡在黄金分割点：每个问题都标注“考察维度”+“易错陷阱”+“面试官追问链”。比如“String str = new String(“abc”)创建了几个对象？”——它不只告诉你“1个或2个”，而是拆解：

考察维度：字符串常量池机制、new关键字内存分配、JDK版本差异（JDK7后常量池移到堆）；
易错陷阱：忽略intern()方法的动态影响、混淆“对象”与“引用”的概念、默认JDK6环境导致结论错误；
追问链：如果接着问“如何证明常量池在堆中？”，你要答“用jmap -histo:live pid看String实例数，配合-XX:+PrintStringTableStatistics参数”；如果问“为什么JDK7要移动常量池？”，你要答“避免永久代OOM，使GC更可控”。
这种设计让每道题都成为“思维脚手架”，而不是记忆负担。当你练熟50道这样的题，大脑会自动形成条件反射：听到关键词→触发考点树→预判追问路径→组织回答逻辑。这才是“八股”真正的生产力。

1.3 别再被“ROI低”误导：八股文是职场跃迁的「最小可行杠杆」

摘要里说“实际工作中作用不大”，这话对一半——对写CRUD接口的日常确实如此，但对争取关键项目、晋升答辩、技术方案评审，它就是你的“信用凭证”。某次架构评审会上，同事提出用Redis List做任务队列，你当场指出“List的LPUSH+BRPOP在节点故障时存在消息丢失风险，建议改用Stream+Consumer Group”，并说出RDB/AOF混合持久化对恢复的影响——这句话的价值，远超你上周写的200行业务代码。因为领导听懂了：你不仅知道怎么用，更清楚边界在哪、风险在哪、替代方案是什么。这种判断力，正是八股文训练出的“技术直觉”。它不直接产出需求，但决定了你能否拿到高价值需求；它不解决具体Bug，但让你在复盘时一眼锁定根因。所以别再说“ROI低”，要问“我的杠杆支点在哪”——而这份资源，就是帮你把支点焊死在Redis、MySQL、并发、算法、数据结构这五根主梁上。

2. 高频考点：Redis三大核心场景与七类致命误用（附真题逐题拆解）

Redis不是“缓存工具”，而是分布式系统里的“状态协调中枢”。面试官考Redis，从来不是问“怎么存取数据”，而是考你如何用它解决一致性、可用性、分区容忍性的三角难题。这份八股文把Redis考点压缩为三大场景：缓存治理（穿透/击穿/雪崩）、分布式锁（Redlock争议与降级方案）、消息队列（Stream vs Pub/Sub取舍）。每个场景下，都藏着面试官最爱挖的“坑”——比如问“如何防止缓存穿透”，如果你只答“布隆过滤器”，他会冷笑：“布隆过滤器本身不占内存？它失效了怎么办？布谷鸟过滤器了解吗？”——这就是典型的知识断层。下面用真题带你踩坑、填坑、建坑。

2.1 缓存穿透：布隆过滤器不是银弹，它的三个反模式必须避开

真题1：用户ID为负数的请求打到数据库，导致缓存穿透。你用布隆过滤器拦截，但线上发现过滤器内存暴涨，QPS下降30%。请分析原因并给出优化方案。

错在哪：认为布隆过滤器是“零成本”组件，忽略其内存占用与哈希计算开销。
为什么错：布隆过滤器的内存消耗与预期元素数n、误判率p正相关，公式为m = -n*ln(p) / (ln2)^2。若n=1亿、p=0.01，m≈9.6亿bit≈114MB；更致命的是，每次查询需k=7次哈希运算（JDK自带BitSet不支持并发，需加锁），高并发下CPU飙升。
怎么答对：
降维打击：先用“空值缓存”兜底——对查不到的key，缓存null值3-5分钟，并加随机过期时间防雪崩；
精准布隆：布隆过滤器只存“合法用户ID范围”，如ID∈[1, 10^9]，用Range Filter替代全量Filter；
异步加载：布隆过滤器用Caffeine本地缓存+Redis分布式缓存双层，本地缓存失效时异步刷新，避免穿透到Redis。

// 布隆过滤器优化示例：使用RedisBloom模块的TOPK // 1. 初始化TOPK：BF.RESERVE user_id_bf 0.01 10000000 // 2. 插入：BF.ADD user_id_bf "12345" // 3. 查询：BF.EXISTS user_id_bf "12345" // 优势：内存占用比传统布隆低40%，支持动态扩容，且RedisBloom是C实现，性能碾压Java版

代码说明：这段Redis命令演示了用RedisBloom模块替代Java布隆过滤器的实操路径。BF.RESERVE预分配空间，BF.ADD插入元素，BF.EXISTS查询——所有操作都在Redis服务端完成，避免网络IO和序列化开销。参数0.01是误判率，10000000是预估元素数，模块会自动选择最优哈希函数和位图大小。相比Java端布隆，它省去了序列化/反序列化、网络传输、客户端CPU计算三重损耗，实测QPS提升5倍以上。

2.2 分布式锁：Redlock已死？面试官要听的是“降级思维”而非站队

真题2：你们用Redisson实现分布式锁，但运维反馈集群脑裂时出现双写。你坚持Redlock方案，CTO要求你48小时内给出可落地的降级方案。请描述你的技术决策链。

错在哪：把Redlock当作唯一真理，忽视CAP理论下P（分区容忍性）的不可妥协性。
为什么错：Redlock依赖多个独立Redis节点，当网络分区发生时，两个客户端可能分别在不同分区获得锁，导致数据不一致。Martin Kleppmann早在2016年就证伪了Redlock的正确性，Antirez（Redis作者）也承认其在分区场景下无法保证安全性。
怎么答对：
承认局限：“Redlock在单机房、低延迟网络下可靠，但跨机房或高延迟网络下，我们必须接受‘最多一次’语义”；
三级降级：
L1：本地锁（ReentrantLock）+ Redis锁双检，本地锁失败直接返回，避免Redis压力；
L2：Redis锁失败时，用ZooKeeper临时节点做最终仲裁（ZK的ZAB协议保证强一致性）；
L3：业务层幂等（如订单号全局唯一+状态机校验），让“锁失效”变成“可重试操作”。
监控兜底：用Redis的INFO replication命令实时监控主从延迟，延迟>100ms时自动切到L2降级。

参数说明：INFO replication返回的master_repl_offset与slave_repl_offset差值即为复制延迟。当差值持续>100000（约100ms），说明从节点落后严重，此时Redlock的“多数派确认”已失效，必须触发降级。这个阈值不是拍脑袋，而是根据业务SLA（如支付订单要求99.99%请求延迟<200ms）反推得出。

2.3 Stream消息队列：为什么90%的团队用错了GROUP消费模型？

真题3：用Redis Stream做订单通知，消费者组内3个实例，但部分消息被重复消费。你检查XREADGROUP命令无误，日志显示ACK延迟高达5秒。请定位根因并修复。

错在哪：认为XREADGROUP天然保证“恰好一次”，忽略ACK超时机制与消费者处理能力的匹配。
为什么错：Stream的XREADGROUP默认NOACK，消息读取后立即进入Pending List；若消费者处理超时（XGROUP SETID设置的idle时间），消息会被重新分配给其他消费者，导致重复。而5秒ACK延迟，远超默认idle=0（即永不超时）的配置，说明你手动设置了过短的idle值。
怎么答对：
调优Pending List：用XPENDING order_stream group1 - + 10查看积压消息，确认是否因消费者崩溃导致；
动态idle：将XGROUP SETID的idle设为“处理耗时的3倍”，如平均处理200ms，则设idle=600；
死信队列：用XADD dlq_stream * event_type "order_timeout"将超时消息转入死信流，人工干预。

# 正确的Stream消费链路（含监控） # 1. 创建消费者组（设置合理idle） XGROUP CREATE order_stream group1 $ MKSTREAM XGROUP SETID order_stream group1 $ IDLE 600 # 2. 消费并ACK（注意：必须在业务逻辑成功后执行） XREADGROUP GROUP group1 consumer1 COUNT 10 BLOCK 5000 STREAMS order_stream > # 3. 监控Pending List水位（告警阈值：pending > 1000） XPENDING order_stream group1 - + 1000

逻辑说明：这段命令链展示了生产环境Stream的正确用法。XGROUP SETID的IDLE 600确保消息在Pending List中至少停留600ms才被重分配，给消费者充足处理时间；XREADGROUP的BLOCK 5000让客户端在无消息时阻塞5秒，避免空轮询；XPENDING作为监控指令，应集成到Prometheus+Grafana中，当pending数量突增时自动触发告警。记住：Stream不是Kafka，它没有内置的offset管理，所有可靠性都靠你精细调控参数。

2.4 易错题：Redis七大“看似正确实则翻车”的操作

错用DEL删除大Key
- 错在哪：DEL big_hash_key在主线程阻塞，导致Redis卡顿。
- 正确做法：HSCAN分批删除+UNLINK（异步删除，Redis 4.0+）。
- 面试官想听：UNLINK会将key元数据立即删除，value对象放入单独的异步线程清理，避免主线程阻塞。
用GETSET实现计数器
- 错在哪：GETSET counter 0在高并发下丢失自增，因GETSET不是原子累加。
- 正确做法：INCRBY counter 1或EVAL脚本保证原子性。
- 面试官想听：INCRBY是Redis原生命令，比Lua脚本更轻量，且支持整数溢出保护。
忽略Redis的LRU淘汰策略缺陷
- 错在哪：认为maxmemory-policy allkeys-lru能精准淘汰冷数据，实际是近似LRU（仅采样20个key）。
- 正确做法：JDK8+用LinkedHashMap实现精确LRU，或用Redis 6.0+的allkeys-lfu（热度优先）。
- 面试官想听：LFU通过衰减因子（lfu-log-factor）控制热度衰减速度，避免短期热点长期霸占内存。
用EXPIRE设置Session过期
- 错在哪：EXPIRE session:123 1800在主从切换时可能丢失过期时间。
- 正确做法：SETEX session:123 1800 "data"，SETEX是原子命令，过期时间随数据一起持久化。
- 面试官想听：Redis的过期时间存储在内部字典中，EXPIRE需额外写入，而SETEX一步到位。
盲目开启AOF everysec
- 错在哪：认为appendfsync everysec绝对安全，实际在OS崩溃时可能丢失2秒数据。
- 正确做法：appendfsync always（牺牲性能保安全）或no-appendfsync-on-rewrite yes（重写时不阻塞AOF）。
- 面试官想听：always模式下，每次写操作都fsync到磁盘，但会拖慢QPS；no-appendfsync-on-rewrite在AOF重写期间暂停AOF同步，避免双重IO压力。
用KEYS * 扫描线上库
- 错在哪：KEYS *阻塞Redis单线程，导致所有请求超时。
- 正确做法：SCAN 0 MATCH user:* COUNT 100，SCAN是渐进式扫描，不阻塞。
- 面试官想听：COUNT参数不是精确返回数量，而是“每次扫描的槽位数”，实际返回可能少于该值。
忽略Redis Cluster的Hash Tag
- 错在哪：MGET user:1:name user:1:age在集群中可能路由到不同节点，导致MGET失败。
- 正确做法：MGET {user:1}:name {user:1}:age，用{}包裹相同前缀，强制路由到同一slot。
- 面试官想听：Redis Cluster的slot计算基于{}内的字符串，这是实现多key操作的唯一合规方式。

3. 高频考点：MySQL索引失效的十二种“血泪现场”与执行计划解读术

MySQL面试题里，90%的“为什么慢”都指向索引失效。但很多人只会背“最左前缀原则”，却答不出“为什么LIKE '%abc'不走索引”——因为没理解B+树的物理结构。这份八股文把索引失效归为三类根源：数据结构限制（B+树无法跳过前导列）、优化器误判（统计信息不准导致选错索引）、SQL写法陷阱（隐式类型转换/函数包裹）。下面用真题带你穿透执行计划（EXPLAIN）的每一行，看清MySQL到底在想什么。

3.1 索引失效第一现场：B+树的“前导列诅咒”

真题4：表order有联合索引(user_id, status, create_time)，但SELECT * FROM order WHERE status='paid' AND create_time>'2023-01-01'不走索引。请解释原因并给出两种优化方案。

错在哪：把联合索引当成“多个单列索引”的叠加，忽略B+树的有序存储本质。
为什么错：B+树索引按(user_id, status, create_time)三列顺序排序，数据物理上先按user_id分组，组内再按status排序，status相同时再按create_time排序。当查询条件缺失user_id（前导列），MySQL无法定位到B+树的某个分支，只能全表扫描。
怎么答对：
重建索引：将高频查询列前置，建(status, create_time, user_id)，但需权衡写入性能（索引越多，INSERT越慢）；
覆盖索引：SELECT status, create_time FROM order WHERE status='paid' AND create_time>'2023-01-01'，用EXPLAIN确认Extra字段为Using index（索引覆盖，无需回表）。

-- 查看执行计划的关键字段解读 EXPLAIN SELECT * FROM `order` WHERE status='paid' AND create_time>'2023-01-01'; -- 输出关键列： -- type: ALL（全表扫描）→ 说明未用索引 -- key: NULL → 未选择任何索引 -- rows: 1000000 → 预估扫描行数 -- Extra: Using where → 在Server层过滤，非引擎层

参数说明：EXPLAIN的type列是核心指标：const（主键等值）最快，ref（非唯一索引等值）次之，range（范围查询）尚可，ALL（全表扫描）最差。key为NULL是硬伤，说明优化器放弃所有索引。rows值越大，性能越差；若rows接近表总行数，基本可判定索引失效。Extra中的Using index表示覆盖索引，Using filesort表示需要额外排序（性能杀手），Using temporary表示创建临时表（更致命）。

3.2 索引失效第二现场：优化器的“统计信息幻觉”

真题5：同样SQL，测试库走索引，生产库全表扫描。SHOW INDEX显示索引存在，ANALYZE TABLE后仍无效。请诊断根因。

错在哪：认为ANALYZE TABLE能一劳永逸，忽略统计信息的采样偏差。
为什么错：MySQL的统计信息（cardinality）通过采样估算，当数据倾斜严重时（如90%的status='pending'，10%的status='paid'），采样可能只扫到pending数据，误判status='paid'为高基数，从而放弃索引。
怎么答对：
强制索引：SELECT * FROM order FORCE INDEX(idx_status_time) WHERE status='paid'...，但属临时方案；
重建统计信息：ANALYZE TABLE order PERSISTENT FOR ALL;（MySQL 8.0+），开启持久化统计，避免重启丢失；
终极方案：用OPTIMIZE TABLE order重建表+索引，彻底刷新统计信息（需锁表，安排在低峰期）。

对比表：统计信息刷新方式效果对比

方式	命令	是否持久化	是否锁表	适用场景
采样更新	`ANALYZE TABLE t`	否（重启丢失）	否	快速验证，开发环境
持久化更新	`ANALYZE TABLE t PERSISTENT FOR ALL`	是	否	生产环境首选，MySQL 8.0+
彻底重建	`OPTIMIZE TABLE t`	是	是	统计信息严重失真，且允许短时锁表

提示：OPTIMIZE TABLE本质是ALTER TABLE ... ENGINE=InnoDB，会重建整个表，耗时长但效果最彻底。线上务必用pt-online-schema-change工具在线执行。

3.3 索引失效第三现场：SQL写法的“温柔陷阱”

真题6：SELECT * FROM user WHERE phone = 13812345678，phone是VARCHAR类型，但执行计划显示type=ALL。请定位问题。

错在哪：忽略隐式类型转换，以为字符串数字和数字类型能自动匹配。
为什么错：phone是字符串类型，而13812345678是数字字面量，MySQL会将phone列所有值转为数字再比较（CAST(phone AS SIGNED)），导致索引失效。
怎么答对：
显式转换：WHERE phone = '13812345678'，用字符串字面量；
函数索引（MySQL 8.0+）：CREATE INDEX idx_phone_num ON user ((CAST(phone AS UNSIGNED)))；
业务层校验：输入时统一格式化为字符串，避免前端传数字类型。

-- 验证隐式转换的EXPLAIN输出 EXPLAIN SELECT * FROM user WHERE phone = 13812345678; -- Extra: Using where; Bad null check → 明确提示类型转换 EXPLAIN SELECT * FROM user WHERE phone = '13812345678'; -- key: idx_phone → 正确使用索引

逻辑说明：EXPLAIN的Extra字段出现Bad null check是隐式转换的铁证。它表示MySQL在执行WHERE条件前，对列做了非预期的类型转换。解决方案必须从源头杜绝——要么让SQL字面量类型匹配列类型，要么用函数索引将转换逻辑固化到索引中。记住：任何对索引列的函数操作（如UPPER(name)、DATE(create_time)）都会导致索引失效，这是铁律。

3.4 易错题：MySQL索引失效的十二个“温柔陷阱”

对索引列使用函数
- 错：WHERE YEAR(create_time) = 2023
- 对：WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'
隐式类型转换（数字vs字符串）
- 错：WHERE id = '123'（id是INT）
- 对：WHERE id = 123（保持类型一致）
LIKE以通配符开头
- 错：WHERE name LIKE '%abc'
- 对：WHERE name LIKE 'abc%'或用全文索引MATCH(name) AGAINST('abc')
OR连接非索引列
- 错：WHERE a=1 OR b=2（b无索引）
- 对：为b列单独建索引，或改用UNION（SELECT ... WHERE a=1 UNION SELECT ... WHERE b=2）
索引列参与计算
- 错：WHERE price * 1.1 > 100
- 对：WHERE price > 100 / 1.1
NOT IN子查询（含NULL）
- 错：WHERE id NOT IN (SELECT id FROM banned WHERE id IS NOT NULL)
- 对：WHERE NOT EXISTS (SELECT 1 FROM banned b WHERE b.id = t.id)
ORDER BY与索引顺序不一致
- 错：索引(a,b)，ORDER BY b,a
- 对：ORDER BY a,b或建(b,a)索引
SELECT * 导致回表过多
- 错：宽表+大索引，SELECT *引发大量IO
- 对：只查必要字段，或建覆盖索引
索引选择性过低
- 错：为性别列建索引（只有男/女，选择性≈0.5）
- 对：删除该索引，用WHERE过滤后内存排序
JSON列无法直接索引
- 错：WHERE>// JDK8 ConcurrentHashMap putVal关键片段（简化） final V putVal(K key, V value, boolean onlyIfAbsent) { Node<K,V>[] tab; Node<K,V> f; int n, i; if ((tab = table) == null || (n = tab.length) == 0) tab = initTable(); // 懒初始化 if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 无冲突，CAS插入 if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null))) break; } else if ((fh = f.hash) == MOVED) // 正在扩容，协助迁移 tab = helpTransfer(tab, f); else { V oldVal = null; synchronized (f) { // 关键！锁住整个桶 if (tabAt(tab, i) == f) { if (fh >= 0) { // 链表 binCount = 1; for (Node<K,V> e = f;; ++binCount) { if (e.hash == hash && ((k = e.key) == key || (k != null && key.equals(k)))) { oldVal = e.val; if (!onlyIfAbsent) e.val = value; break; } Node<K,V> pred = e; if ((e = e.next) == null) { pred.next = new Node<K,V>(hash, key, value, null); break; } } } else if (f instanceof TreeBin) // 红黑树 oldVal = (p = ((TreeBin<K,V>)f).putTreeVal(hash, key, value)); } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) // 链表转树阈值 treeifyBin(tab, i); } } return oldVal; }
  代码说明：这段源码揭示了JDK8的真相——synchronized (f)锁住的是当前桶（Node数组的某个位置），而非整个Map。当多个线程同时向同一个桶put，就会在此处竞争。TREEIFY_THRESHOLD=8是链表转红黑树的阈值，但treeifyBin本身不加锁，若多个线程同时触发，会因CAS失败而反复重试，加剧竞争。因此，降低单桶负载（增大初始容量）比纠结“分段锁vs CAS”更有效。
  4.2 锁优化第二山：偏向锁的“甜蜜陷阱”与关闭时机
  真题8：新上线服务启用了偏向锁（JVM默认），但压测发现QPS比关闭偏向锁低15%。请解释现象并给出决策依据。
  错在哪：把偏向锁当作“永远的性能加速器”，忽视其撤销开销。
  为什么错：偏向锁的撤销需要Stop-The-World（STW），当多个线程竞争同一把偏向锁时，JVM必须暂停所有线程，遍历所有线程栈找到持有锁的线程，再将其锁对象头恢复为无锁状态——这个过程比直接用轻量级锁更重。
  怎么答对：
  1. 监控撤销次数：-XX:+PrintBiasedLockingStatistics -XX:+UnlockDiagnosticVMOptions，查看biased_lock_revocation_count；
  2. 关闭时机：若revocation_count > 1000/minute，果断-XX:-UseBiasedLocking；
  3. 替代方案：用-XX:BiasedLockingStartupDelay=5000延迟5秒启用，避开启动期高竞争。
  参数说明：PrintBiasedLockingStatistics会输出详细的偏向锁统计，包括total revocations（总撤销次数）、revoked per second（每秒撤销数）。当撤销频率超过阈值，说明应用存在大量锁竞争，偏向锁已从“甜点”变成“毒药”。此时关闭它，让JVM直接走轻量级锁路径，反而更高效。
  4.3 JMM第三山：volatile的“半同步”本质与内存屏障
  真题9：private volatile boolean flag = false;，线程A执行flag = true;，线程B循环while(!flag){}。为什么B能立即看到A的修改？请用内存屏障解释。
  错在哪：只答“volatile保证可见性”，不说清“如何
  本文还有配套的精品资源，点击获取