java虚拟线程Java 线程 操作系统线程的 1:1 包装。java线程缺点内存开销大CPU上下文频繁切换每个线程默认栈 512KB~1MB1万并发 10GB阻塞时浪费阻塞性线程阻塞在IO时OS线程挂起CPU闲置创建销毁慢系统调用级别微秒级开销虚拟线程M:N映射避免了CPU上下文频繁切换虚拟线程百万级 ↓ 调度 载体线程池Platform Thread数量CPU核心数--java线程 ↓ OS 线程 → CPU阻塞时自动卸载–非阻塞性虚拟线程 发起 IO 阻塞 → JVM 检测到阻塞点 → 将虚拟线程从载体线程 Unmount保存栈帧到堆 → 载体线程立即去执行其他虚拟线程 → IO 完成后虚拟线程被重新 Mount 到载体线程继续执行虚拟线程的缺点Pinning钉住问题–RetrantLock解决synchronized 块内阻塞时载体线程无法释放退化为平台线程行为// ❌ 这段代码在虚拟线程下会 Pinningsynchronized(lock){Thread.sleep(1000);// 阻塞 → 载体线程被钉住}// ✅ 改用 ReentrantLocklock.lock();try{Thread.sleep(1000);// 阻塞 → 正常 Unmount}finally{lock.unlock();}题目归类题目类别掌握重点MVCCMySQL并发ReadView生成时机是RC vs RR的分水岭Redis数据类型缓存每种类型的底层结构 自己项目的使用MQ持久化消息队列三件套缺一不可 Confirm 手动ACKAQS并发框架state CLH队列 park/unparkReentrantLock公平/非公平并发hasQueuedPredecessors()是核心区别CAS原理并发Unsafe CMPXCHG指令 自旋CAS解决ABA并发AtomicStampedReference 版本号三级缓存Spring三层缓存职责 为何需要第三级AOP代理数据库隔离级别MySQLMySQL默认RR开启事务后只生成一份ReadView快照Oracle默认RC每次select 生成新的 ReadView快照MVCC读不加锁写不阻塞读——读写可以真正并发。系统问题 如果没有 MVCC数据库实现隔离级别如RR 可重复读事务问题–事务隔离级别行锁、表锁三种问题未解决–未提交读脏读一读已提交(行锁读不会加锁)不可重复度—重复读(行锁读和写都会上锁)幻影读–串行化(表锁)核心原理以 MySQL InnoDB 为例其 MVCC 的实现依赖于三个隐式字段、Undo Log 和 Read View。记录当前事务的信息隐式字段当前事务ID及回滚事务Roll ID以链Undo Log的形式存储此事务顺序事务开启时生成Read View快照随时记录活跃事务ID已触发该事务但未提交的一些、活跃最小ID最初开启的且未提交的事务、分配给下一个事务ID未来会触发的事务ID默认累加标识、生成ReadView快照时当前的事务ID(creator_trx_id)读取规则若生成快照事务ID当前事务ID可以读取访问若当前事务ID 活跃事务DI 说明已经提交且事务完成销毁了可以访问若当前事务ID 下一个事务ID未来事务不可以访问若活跃最小ID 当前事务 未来事务ID若 当前事务 包含于 活跃事务ID不可以文档未提交若 当前事务 不包含于 活跃事务ID可以访问已完成且销毁Undo Log版本链每当记录被修改InnoDB 会把旧版本写入 Undo Log 中。通过 DB_ROLL_PTR这些旧版本串联成一个版本链。[最新版本]--ROLL_PTR--[版本N]--ROLL_PTR--[版本N-1]--... --[最初版本]隐式字段每行记录后面其实都隐藏了三个字段DB_TRX_ID最后一次修改该记录的事务 ID。DB_ROLL_PTR回滚指针指向 Undo Log 中的上一个版本。DB_ROW_ID隐藏的主键如果没显式定义主键。ReadViewRC与 RR 的应用场景举例RR可重复读整个事务只生成一次 Read View两次 select 复用同一份。第一次 select → axing3第二次 select → axing3Read View 不变结果一致RC读已提交每次 select 都重新生成 Read View。如果事务101在第二次select前提交了新 Read View 的 m_ids[104]101 不再活跃trx_id101 可见 → 第二次 select 返回 axing1这就是不可重复读问题转账场景—RR优势你在做一份月度财务报表需要统计账户A、账户B、账户C的余额计算总和。第1步查账户A余额 → 1000元 此时另一个事务把A转给B 500元并提交了 第2步查账户B余额 → 1500元读到了转账后的新值 第3步查账户C余额 → 500元 汇总1000 1500 500 3000元 ← 错的 实际应该是500 1500 500 2500元RC 每次都读最新数据导致同一事务内前后读到的是不同时间点的状态数据在逻辑上不一致。这就是不可重复读问题在报表、对账、业务校验等场景下是灾难性的。RR 的价值正在于此RR 保证同一事务内无论外部怎么提交你看到的世界是一致的快照。事务开始生成一次 Read View 第1步查账户A余额 → 1000元快照时的值 外部转账提交但我的快照不变 第2步查账户B余额 → 1000元快照时的值看不到转账 第3步查账户C余额 → 500元 汇总1000 1000 500 2500元 ← 正确库存实时查询–RC优势用户在商品详情页看库存数量要求展示尽可能实时的库存不需要跨步骤的一致性保证。用户在商品详情页看库存数量要求展示尽可能实时的库存不需要跨步骤的一致性保证。商品库存初始100件 事务A仓库管理员 事务B用户刷商品页 ──────────────────────────────────────────────── update stock80commit;✅ 已提交selectstock →80← 读到最新 ✅ update stock60commit;✅ 已提交selectstock →60← 读到最新 ✅RC 每次 select 重新生成 Read View用户每次刷页都能看到最新库存。/** * RC级别每次查询都读最新库存 * 适合商品详情页实时展示库存 */Transactional(isolationIsolation.READ_COMMITTED)publicvoidshowRealtimeStock(LongproductId){// 第一次查询intstock1stockMapper.selectStock(productId);System.out.println(第一次查询库存stock1);// 100// 模拟用户停留页面此时仓库管理员提交了扣减操作// 仓库update stock 80 → commit// 第二次查询RC重新生成ReadView读到最新intstock2stockMapper.selectStock(productId);System.out.println(第二次查询库存stock2);// 80 ← 读到最新值 ✅}所以 RC 和 RR 不是谁更好是适用场景不同RC 读已提交RR 可重复读数据新鲜度始终最新事务开始时的快照一致性保证弱同一事务可能读到不同版本强整个事务视图一致适合场景对实时性要求高、单次查询为主报表、对账、涉及多步骤读的业务逻辑MySQL默认❌✅Redis 数据类型详解五大基础类型1. String — 最基础用途最广底层SDSSimple Dynamic StringO(1)获取长度 redisTemplate.opsForValue().set(quota:user:1001,100);redisTemplate.opsForValue().increment(counter:pv);// 原子自增 redisTemplate.opsForValue().setIfAbsent(lock:order,1,30, TimeUnit.SECONDS);// 分布式锁适用场景 缓存、计数器、分布式锁、Session存储2. Hash — 对象存储首选java// 底层listpack小数据量/ hashtable redisTemplate.opsForHash().put(user:1001,name,小明);redisTemplate.opsForHash().put(user:1001,age,25);redisTemplate.opsForHash().get(user:1001,name);适用场景 存对象购物车、用户信息。比序列化整个JSON更节省空间可单字段修改3. List — 有序列表支持两端操作java// 底层listpack小/ quicklist大多个ziplist串联 redisTemplate.opsForList().leftPush(mq:task,task1);// 生产 redisTemplate.opsForList().rightPop(mq:task);// 消费FIFO redisTemplate.opsForList().range(timeline:user:1,0,9);// 最新10条适用场景 消息队列简单场景、朋友圈时间线、最新N条记录4. Set — 无序不重复集合java// 底层intset全整数小集合/ hashtable redisTemplate.opsForSet().add(tag:java,user1,user2,user3);redisTemplate.opsForSet().intersect(tag:java,tag:redis);// 共同标签 redisTemplate.opsForSet().isMember(blacklist,ip:1.2.3.4);// 黑名单判断适用场景 去重UV统计、共同好友/标签、黑白名单5. ZSetSorted Set— 有序集合带分数java// 底层listpack小/ skiplist hashtable大 redisTemplate.opsForZSet().add(rank:game,player1,9800.0);redisTemplate.opsForZSet().add(rank:game,player2,9500.0);redisTemplate.opsForZSet().reverseRangeWithScores(rank:game,0,9);// 排行榜Top10 // 延迟队列score执行时间戳 redisTemplate.opsForZSet().add(delay:queue,task:order_timeout, System.currentTimeMillis() 30_000);适用场景 排行榜、带优先级的任务队列、延迟队列、范围查找CAS–AQS–ReentratLock比较并交换CAS本质Compare And Swap比较并交换if(内存值期望值){内存值新值 // 交换成功}else{// 交换失败说明被别人改了}// 以上操作是 CPU 原子指令不可分割解决ABA问题版本号CAS/AQS/ReentrantLock关系CAS ←──────────────── 最底层CPU原子指令 │ ▼ AQS ←──────────────── 基于CAS管理state和队列构建同步器骨架 │ ▼ ReentrantLock ←──────── 基于AQS实现提供可中断/超时/多条件等高级能力AQS三要素① state一个 int表示锁状态 ② CLH队列双向链表存放等待的线程 ③ 两个核心操作acquire抢锁/ release释放// AQS 核心结构简化publicabstractclassAbstractQueuedSynchronizer{privatevolatileintstate;// 核心状态位// 队列节点staticfinalclassNode{Threadthread;// 等待的线程Nodeprev;// 前驱Nodenext;// 后继intwaitStatus;// 节点状态}// 子类实现这两个方法定义抢锁和释放的逻辑protectedbooleantryAcquire(intarg){thrownewUnsupportedOperationException();}protectedbooleantryRelease(intarg){thrownewUnsupportedOperationException();}}抢锁流程线程来了 │ ▼ tryAcquire()能抢到 ├─ 是 → state1记录当前线程直接干活 ✅ │ └─ 否 → 封装成Node加入CLH队列尾部 │ ▼ LockSupport.park()挂起等待唤醒 │ ▼ 前驱节点释放锁后 unpark()唤醒我 │ ▼ 重新 tryAcquire()基于 AQS 的全家桶AQS ├─ ReentrantLock 独占锁 ├─ ReentrantReadWriteLock读写锁 ├─ Semaphore 信号量 ├─ CountDownLatch 倒计时 └─ CyclicBarrier 屏障AQS 是骨架子类只需实现 tryAcquire / tryRelease队列管理、线程挂起唤醒全由 AQS 搞定。ReentrantLock公平/非公平公平必须排队检查队列是否有等待者非公平先直接CAS抢一次锁抢不到再排队中断抢锁可被其他线程中断ReentrantLocklocknewReentrantLock();// 死等但可以响应中断try{lock.lockInterruptibly();// 其他线程interrupt()我我可以退出// 干活}catch(InterruptedExceptione){System.out.println(被中断了不等了);}finally{if(lock.isHeldByCurrentThread())lock.unlock();// 我退出了}场景用户取消操作不应该让线程继续傻等锁。超时抢锁ReentrantLocklocknewReentrantLock();// 最多等3秒抢不到就算了booleanacquiredlock.tryLock(3,TimeUnit.SECONDS);场景接口超时控制抢不到锁直接返回降级结果不影响用户体验。与 Redis分布式锁区别tryLock()同一个JVM进程内多个线程之间抢锁【单体应用】Redis分布式锁多台服务器**多个进程**之间抢锁【分布式环境】多条件队列 ConditionCondition 的解法多个等待室等待室AnotFull专门放生产者 等待室BnotEmpty专门放消费者 生产者放完数据 → 只叫醒等待室B的消费者 消费者取完数据 → 只叫醒等待室A的生产者 精准通知互不干扰Condition vs wait/notify// 生产者消费者用 synchronized wait/notify synchronized(lock){while(队列满)lock.wait();// 生产者等 // 放入数据 lock.notifyAll();// ← 只能通知所有人 // 本来只想通知消费者 // 结果把其他生产者也叫醒了 // 醒了发现队列还是满的再sleep // 白白浪费}// 生产者消费者用 synchronized wait/notify synchronized(lock){while(队列满)lock.wait();// 生产者等 // 放入数据 lock.notifyAll();// ← 只能通知所有人 // 本来只想通知消费者 // 结果把其他生产者也叫醒了 // 醒了发现队列还是满的再sleep // 白白浪费}Spring 三级缓存解决循环依赖“三级缓存解决循环依赖的核心是先把半成品Bean的工厂放入三级缓存当另一个Bean需要它时从三级缓存获取早期引用此时可触发AOP代理生成放入二级缓存满足注入需求最终Bean完成初始化后进入一级缓存。三级缓存的意义在于延迟代理对象的生成确保循环依赖场景下AOP代理和普通Bean使用同一个对象引用。”三级缓存// DefaultSingletonBeanRegistry 中的三个Map// 一级成品完整初始化的BeanMapString,ObjectsingletonObjectsnewConcurrentHashMap();// 二级半成品已实例化但未填充属性/未初始化MapString,ObjectearlySingletonObjectsnewHashMap();// 三级工厂存Bean的ObjectFactory用于生成代理对象MapString,ObjectFactory?singletonFactoriesnewHashMap();详细解决步骤Step1: 开始创建A → 一、二、三级缓存都没有A → 反射实例化A此时A是空壳属性未填充 → 将A的ObjectFactory放入【三级缓存】 → 开始填充A的属性发现需要B Step2: 开始创建B → 三级缓存都没有B → 反射实例化B空壳 → 将B的ObjectFactory放入【三级缓存】 → 开始填充B的属性发现需要A Step3: 获取AB需要A → 查一级缓存没有 → 查二级缓存没有 → 查三级缓存找到A的ObjectFactory → 调用ObjectFactory.getObject()获得A的早期引用可能是代理 → 将早期A放入【二级缓存】删除三级缓存中的A → B的属性a早期A ✓ Step4: B创建完成 → B完成初始化属性填充、BeanPostProcessor → B放入【一级缓存】清除二三级缓存中的B Step5: 回到AA继续填充属性 → A的属性b已完成的B ✓ → A完成初始化 → A放入【一级缓存】清除二三级缓存中的A 最终A持有BB持有的是A的早期引用 因为是同一个对象引用A完成初始化后B拿到的也是完整的A为什么需要三级而不是二级关键AOP代理问题 如果A需要被AOP代理那最终放入一级缓存的应该是代理A而不是原始A。 三级缓存的ObjectFactory作用()-getEarlyBeanReference(beanName, mbd, bean)↓ 调用所有SmartInstantiationAwareBeanPostProcessor ↓ 如果需要AOP代理此时生成代理对象 如果只有二级缓存 B拿到的是原始A而一级缓存放的是代理A B.a ≠ 一级缓存中的A → 引用不一致 三级缓存保证无论A是否需要代理B拿到的引用 和最终一级缓存中的A是同一个对象