- 博客(75)
- 收藏
- 关注
RSS订阅原创 重塑 Java 世界的两根支柱：穿透 Spring IoC 与 AOP 的架构哲学
在 Java 漫长的发展史中，如果没有 Spring 框架的诞生，企业级开发可能至今仍在一片泥潭中挣扎。与。在经历了前面的学习后，我们已经分别拆解了 Bean 的创建演进、动态代理的内存魔术，以及切面语法的脱胎换骨。今天，我们将站上一个更高的维度，将这些散落的知识点拼图合二为一，来一场 Spring Core 的终极复盘。
2026-05-31 21:40:45
44
原创 从繁琐到极简，从幻象到本质：Spring AOP 架构演进与实战避坑指南
为了消灭“强侵入”和“类爆炸”，Spring 2.0 时代引入了纯 XML 配置模式。彻底抛弃 Spring 接口！你只需要写一个极其普通的 Java 类（POJO），把前置逻辑和后置逻辑写成里面的两个普通方法。然后在巨大的 XML 配置文件中，通过标签，手动把这些方法与目标类的切入点“缝合”起来。类的数量减下来了，但 XML 变得臃肿不堪。每次修改方法名，都要在 Java 代码和 XML 之间来回跳转，重构极易出错。
2026-05-31 21:36:07
45
原创 从手写代码到内存“无中生有”：硬核拆解 Java 静态代理与动态代理的架构演进
从手写繁琐的 XML 和静态代理类，到走向动态代理的无中生有，代理模式的演进本质上是“控制权从编译期向运行期”的全面移交。静态代理把结构写死在代码里，换来的是极致的直观，输掉的是灵活性；JDK 动态代理通过接口欺骗和反射，在运行时解放了重复劳动力；CGLIB 则通过底层的字节码操纵进行高空作业，用继承拓宽了代理的物理边界。只有自底向上地看清这些技术在内存中的演进状态，我们在面对 Spring AOP、各类拦截器和分布式微服务的网络调用时，才算真正握住了掌控底层状态机的钥匙。
2026-05-30 22:08:41
449
原创 从拦截洪峰到优雅兜底：微服务 Sentinel 核心原理与实战全指南
真正的架构师懂得，高可用架构的本质是一场关于“妥协”的艺术： 为了保住核心业务链路，我们用限流妥协了部分瞬间涌入用户的体验；为了保住整个微服务集群的存活，我们用熔断妥协了局部的边缘功能。而在这一切背后默默计算阈值、拦截请求的，是 Sentinel 的底层机制；而用温馨的提示和异步补偿逻辑安抚用户的，是我们写下的那一层层优雅的兜底降级代码。两者合一，才是真正的微服务高可用。为了直观体验这套“防御+兜底”组合拳的威力，我为你准备了一个架构级模拟器。
2026-05-30 16:35:05
280
原创 惊鸿一瞥：从Claude源码看顶级 AI Agent 的系统架构
Anthropic 的这次源码泄露，不经意间拉平了 AI 行业的认知差。它无情地撕破了那些鼓吹“只要 Prompt 写得好，Agent 就能跑起来”的伪工程学说。在生产环境中，大模型本身的智力只是那颗 1.6% 的“心脏”，而让它稳如泰山、能干脏活累活的，是外围那 98.4% 坚如磐石的确定性系统工程体系。用坚固的文件树做骨架，用细粒度的工具网关做免疫系统，用无情的压缩管道保护脑容量。让模型在极端受限但绝对安全的轨道里发挥聪慧，这才是工业级 AI Agent 架构的终极奥义。
2026-05-28 22:53:02
1068
原创 带你重走一遍 Spring IoC 从 XML 到注解的进化之路
从 XML 到注解的演进，本质上是软件工程从“集中式配置”向“约定优于配置（Convention Over Configuration）”的理念升级。在今天的实际企业级开发中（尤其是 Spring Boot 时代），我们通常采用混合流派毫无疑问，100% 全面拥抱注解@Service@Autowired等），享受极速开发的快感。既然无法修改别人的源码贴@Component，我们就放弃外部 XML，拥抱现代的（使用配合@Bean注解）来统一管理。
2026-05-28 20:49:07
165
原创 告别 new 对象：彻底搞懂 Spring IoC 的底层逻辑与实战
为了解决这种强耦合，思想应运而生。1. 谁控制谁？在传统开发中，是我们（程序员）在对象内部主动去new另一个依赖的对象。控制权在对象本身。在 Spring 中，专门设计了一个“超级大工厂”——IoC 容器。由 IoC 容器来统一负责对象的创建、配置和生命周期管理。控制权交给了IoC 容器。2. 反转了什么？依赖对象的获取方式被反转了。以前是你主动去“拉（Pull）”依赖对象（new操作）；现在是你只需要声明你需要什么，IoC 容器就会主动把对象“推（Push）”给你。🌟 现实生活中的绝佳比喻：找对象。
2026-05-27 22:30:32
334
原创 告别满屏的 URL 拼接：一篇文章带你彻底搞懂 OpenFeign
OpenFeign是一个声明式的 Web 服务客户端。什么是“声明式”？你只需要声明你想要什么，不需要关心底层是怎么做到的。在 OpenFeign 的世界里，你不需要写任何发送 HTTP 请求的具体代码。你只需要定义一个Java 接口，然后在接口上打上 Spring MVC 的注解（比如），告诉 Feign 这个接口对应远程的哪个 HTTP 路由。Feign 会在底层自动利用动态代理为你生成实现类，并完成 URL 拼接、序列化、发送请求等所有脏活累活。
2026-05-27 20:26:19
326
原创 微服务架构的“动态遥控器”：一篇文章彻底搞懂 Nacos 配置中心与实战
你可能会好奇，Nacos 是怎么做到热更新的？难道是客户端一直在死循环发请求问服务端“配置变了吗”？其实，Nacos 2.x 底层使用了基于gRPC 的长连接。客户端会与 Nacos 服务端建立一条常驻的 gRPC 通道。当我们在控制台修改配置并发布时，服务端会主动顺着这条长连接，将变更事件推送（Push）给客户端。客户端收到事件后，Spring 框架底层的机制被触发，销毁带有注解的旧 Bean，并利用新拉取的配置重新实例化一个新 Bean。
2026-05-25 16:27:57
338
原创 微服务寻址的“智慧大脑”：一篇文章彻底搞懂 Nacos 注册中心与实战
在云原生时代，服务的容器会频繁地销毁、重启、漂移，IP 地址变得像流水一样不可靠。引入 Nacos 这样的注册中心，本质上是增加了一个中间抽象层，用逻辑概念（服务名）解耦了物理概念（IP + 端口）。理解了这一点，你就真正推开了微服务架构的大门。
2026-05-25 16:22:03
556
原创 从底层 CPU 架构看透现代分布式与并发编程
试图打造更强壮的单一节点。发现同质化任务可以由“一个大脑，多手多脚”来暴力拆解。任务复杂后，让多个大脑围着同一块黑板（共享内存）干活，却发现黑板前挤满了人，冲突不断。给每个人发一个小黑板，让他们坐回自己的工位。有事通过打电话（网络通信）来沟通。打电话虽然有网络延迟开销，但这彻底解除了物理资源的深度耦合，是唯一能实现无上限水平扩展（Scale-Out）的光明大道。
2026-05-24 14:21:54
404
原创 从 CPU 硬件多线程的“第一性原理”看透 Java JUC
剥开高级语言优雅的语法糖，Java 并发编程的种种设计模式，其最终目的都是为了迎合硅片内部的物理法则。为了避免粗粒度的高昂代价，我们用非阻塞 I/O 替代阻塞 I/O；为了发挥细粒度的切换优势，我们用 CAS 自旋和虚拟线程榨取低延迟；为了填满SMT的多路发射器，我们用 ForkJoin 模型拆解任务。当我们能够自上而下地贯通 JVM 源码与底层体系结构，并发编程就不再是死记硬背的八股文，而是精密的工程美学。
2026-05-24 14:05:21
349
原创 讲透分布式系统的演进史与核心架构
从单体架构到分布式微服务，这并不是技术的无病呻吟，而是被业务规模逼出来的生存进化。分布式系统本质上是一场“资源的拆分与重新连接”的游戏。它牺牲了单机系统的极简性，引入了复杂的网络延迟、分布式事务、缓存一致性等噩梦级难题，但换来的，是能够承载数亿用户、永不停机、坚如磐石的现代数字基础设施。
2026-05-22 21:31:36
324
1
原创 别让 UI 拖垮你的 Agent：React 架构下接入 MCP 协议的四大“生死局”
在 React 下接入 MCP 构建 Agent，表面上写的是 TypeScript，但实际上，你需要具备操作系统级别的并发调度思维和数据库级别的状态一致性思维。忘掉组件、忘掉 Hooks、忘掉单纯的页面渲染。当你开始构建 Agent 引擎时，你就是在开发一个驻留在浏览器里的、连接大模型与本地物理世界的微型操作系统。跨过这四道生死线，你的应用才真正具备了工业级的可用性。
2026-05-22 21:22:08
335
原创 AI 架构的文艺复兴：用操作系统“内存管理”重构 LLM 状态机 —— 深度解密 Claude Code
高级的 Agent 工程，本质上是数据结构与操作系统算法在 AI 领域的降维应用。在这个范式下，我们必须扭转思维： 不要再试图用无限拉长的 Prompt 去解决所有上下文问题。请让 LLM 成为纯粹的 CPU 控制器（Control Unit），把复杂的状态维护与持久化，交给文件系统这个“硬盘”，用工具调用（Tools）去构建连接它们的 I/O 总线。
2026-05-21 22:51:24
462
原创 个人体验：从零构建高可用 Multi-Agent 架构与实战避坑指南
AI 模型在多轮交互中天然是“近视”的。如果它查了 10 个文件，在最后一步触发时，它往往只会汇报第 10 个文件的结果。解法：追加一轮“述职汇报”。Javai < 15;i++) {// 执行一轮 Think→Act→Observe// 无论是检测到结束标记，还是常规迭代结束，统一进入 requestFinalSummarynextPrompt = "请继续执行任务。// 强制逼问，榨干前置上下文subLoop.processInput("请输出完整总结，涵盖每一步的关键发现。
2026-05-20 22:47:45
822
1
原创 孤胆英雄的黄昏，社会化智能的黎明：一文看透 Multi-Agent 架构底层逻辑
人工智能先驱马文·明斯基（Marvin Minsky）在 1986 年写过一本旷世巨著《心智社会》（The Society of Mind）。他提出，人类的智能本身并不是由一个单一的“超级中心大脑”产生的，而是由无数个极其简单的、只懂一件事的微小智能体（Agents）通过复杂的协作和竞争涌现出来的。四十年前的理论，在今天大语言模型的演进中得到了最完美的印证。Multi-Agent 的本质，就是承认单体大模型的局限性。
2026-05-20 22:36:15
486
原创 扛住十万并发的“冷面保安”：一文扒透限流的四大经典算法与代码实战
高并发架构没有银弹。如果你要保护的是绝对不能承受突发压力的老旧底层数据库，选漏桶。如果你要保护的是对外暴露的 Web API 接口，希望在平时平滑限制，偶尔遇到大促又能扛住一波突发的积攒流量，果断选令牌桶。认清每种算法的脾气，才能给你的服务器配上最合适的“冷面保安”。
2026-05-19 14:49:57
461
原创 如何扛住十万级流量洪峰？扒开高并发架构的五层防御体系
所谓的高并发架构，其实从来没有什么神奇的黑科技，它的本质是一场“资源的调配与妥协的艺术”。为了保护系统的存活，我们妥协了体验，引入了限流与降级。为了化解瞬时的洪峰，我们妥协了实时性，引入了MQ 异步削峰。为了极致的读取速度，我们妥协了强一致性，引入了多级缓存。当你在键盘上敲下每一行代码，设计每一个架构图时，请脑补出那十万并发流量在网线中呼啸而过的画面。理解了这五层防御体系的物理意义，你才能在真正的流量洪峰到来时，稳如泰山。
2026-05-19 14:24:59
593
原创 讲明白Lambda 表达式的进化史
如果你是从 Java 8 之后才开始接触这门语言的，那你无疑是幸运的。在现代的 Java 代码里，我们经常能看到像这样清爽、优雅的代码。但在 Java 8 诞生之前的漫长岁月里，Java 程序员为了实现同样的一句打印，往往要写下十几行不知所云的“废话”代码。为什么会这样？因为 Java 是一门极其纯粹的。这意味着，如果你想传递一段“行为（一段执行逻辑）”，你不能直接把逻辑扔过去，你必须先造一个“对象”，把这段逻辑塞进对象的方法里，然后把整个对象传递过去。
2026-05-18 21:53:55
351
原创 告别阻塞与回调地狱：用 CompletableFuture 构建动态回调枢纽
在复杂的分布式系统中，数据的获取早已不再是线性的，而是网状的。传统的Thread和Future只解决了“并发执行”的问题，却把“结果收集与流转”的烂摊子留给了开发者去用阻塞的方式硬扛。而 CompletableFuture的本质，就是一个自带状态机、内置了回调注册表的并发编排枢纽。它将 Java 的多线程编程从“手工拉纤”的时代，直接跨越到了“自动化流水线”的时代。下次遇到复杂的接口聚合、并发依赖调度，不要再下意识地去写或是循环了。试着把逻辑抽象成一张有向无环图（DAG），然后用将它优雅地表达出来吧！
2026-05-18 15:11:34
326
原创 AI Agent 架构里的隐形杀手：MCP 协议下 ProcessBuilder 的 64KB 死锁陷阱
软件工程界有一句名言：“所有非平凡的抽象都会泄露（All non-trivial abstractions, to some degree, are leaky）。Java 的给我们提供了一个极其简单的“流”抽象，屏蔽了底层的操作系统机制。但在高并发和大数据量的 AI 架构中，底层的 64KB 缓冲区依然无情地刺穿了这层抽象。对于真正的后端架构师来说，只有懂得往下看透物理底层，才能往上写出坚不可摧的业务代码。
2026-05-16 21:29:17
595
原创 为什么到了 2026 年，顶级大厂和 AI 都在疯卷 CLI？
CLI（Command Line Interface，命令行界面），简单来说，就是你通过键盘输入纯文本指令，计算机通过纯文本返回结果的人机交互方式。要理解 CLI，我们必须把它和它的死对头GUI（Graphical User Interface，图形用户界面）放在一起对比。屏幕上有什么按钮，你就能点什么。操作门槛极低，所见即所得。你只能做设计师允许你做的事。如果软件没有提供“批量重命名 1000 个带特定后缀文件”的按钮，你就只能手工点 1000 次，点到鼠标冒烟。
2026-05-16 21:00:32
340
原创 代码空间的“无中生有”：聊聊Java 动态代理的底层原理
从手写繁琐的静态包装，到运行时生成接口的实现，再到突破接口限制生成子类，最后达到无实体调用的境界。Java 的动态代理技术，完美诠释了什么是“在更高维度解决系统耦合理解了它，你就不再是只能堆砌业务逻辑的码农，而是触摸到了现代软件工程架构底层脉络的创造者。
2026-05-14 23:03:41
355
原创 浅聊Java反射
反射就像是 Java 提供给开发者的一把“万能钥匙”和“X光机”。业务开发时把钥匙收好（遵守面向对象规则），框架开发时拿出钥匙（追求极致的灵活性和解耦）。
2026-05-14 22:57:25
344
原创 别让大模型只会“纸上谈兵”：扒开 Agent Skills 的底层逻辑与装配艺术
在前两篇文章中，我们探讨了 Function Calling（让大模型能输出标准指令的“通信协议”）和 Harness（包裹大模型、控制物理交互的“机甲外骨骼”）。现在，你的大模型已经不再是一个被困在黑暗房间里的“缸中之脑”了。它穿上了 Harness 这套钢铁侠战衣，拥有了与外界通信的能力。但是，这套战衣现在是的。它没有装配任何武器，也没有导航雷达。当用户说“帮我把昨天崩溃的服务器重启一下”时，大模型只能在战衣里干瞪眼。。
2026-05-12 22:31:42
376
原创 从马具到 AI 智能体的“外骨骼”：扒开 Harness 的底层进化史
从马背上的皮带，到机房里的线圈；从保护代码的测试桩，到控制 AI 智能体的机甲。剥开层层迷雾，你会发现Harness的本质从未改变：它永远处于“核心实体”与“复杂外部世界”的交界处。它屏蔽混乱、提供接口、保障安全。无论是写业务代码，还是设计 AI 架构，理解并用好 Harness 这种“搭建脚手架”的工程思维，才是拉开普通程序员与顶尖架构师差距的核心关键。
2026-05-12 22:20:15
542
原创 别再把大模型当“缸中之脑”了：扒开 Function Calling（函数调用）的底层运行逻辑
不要被这个英文单词唬住了。在大白话里，Function Calling 就是一种让大模型和外部代码“按规矩对接”的通信协议。在过去，你给大模型一段文字，它返回给你一段文字。有了 Function Calling，你可以在提问的时候，顺便递给大模型一个“工具箱”（里面装满了你提前写好的函数说明书）。大模型在思考后，如果发现解答你的问题需要用到这些工具，它就不会直接回答废话，而是返回一段JSON 代码，告诉你：“兄弟，我算不出来，但请你帮我调用一下工具箱里的函数，参数传入城市：北京。
2026-05-11 10:57:32
1548
1
原创 穿透 MQ 专栏 (五)：【终局之战】MySQL 和 MQ 的世纪联姻：扒开“分布式事务”的遮羞布
读到这篇大结局，你已经陪我走过了 MQ 架构中最泥泞的沼泽。我们用“削峰”保住了服务器的命，用“ACK与落盘”防住了消息丢失，用“状态机”杀死了重复扣款，甚至在百万积压的灾难中完成了一场教科书般的救火。可以说，在单节点系统和纯 MQ 领域，你已经是无敌的存在了。但是，当你回到工位，看着自己写下的那段最核心的“支付回调”代码时，你的背后突然感到一丝凉意。Java你以为加上了这个神圣的注解，就能保证这两行代码“要么全成功，要么全失败”。
2026-05-11 10:43:06
324
原创 穿透 MQ 专栏 (四)：【秩序之争】被杀死的全局顺序：消息乱序与千万级积压的救火指南
在上一篇，我们利用“业务状态机”给消费者穿上了完美的防弹衣，彻底防住了网卡顿导致的“重复扣款”。看着固若金汤的秒杀系统，你觉得已经没有什么能打败你了。直到有一天，老板脸色铁青地把你叫进办公室，指着一条客诉问：“这个用户明明是在下单后立刻点了取消，为什么系统不仅没给他退款，反而把货给他发出了？！你调出日志，瞬间三观崩塌： 扣款系统（生产者）确实是按照顺序发出了两条消息：先发了，紧接着发了。但在物流系统（消费者）这边的日志里，竟然是了 [已取消]，了 [已支付]！物流系统一看，订单还没支付怎么取消？
2026-05-10 21:56:41
404
原创 穿透 MQ 专栏 (二)：【生死契约】“我付了钱，订单却没生成？”：手撕 MQ 的消息丢失与零拷贝黑科技
上一篇，我们在千钧一发之际引入了 MQ，成功挡住了双十一的 10 万并发洪峰。你看着后台平稳运转的 CPU，端起保温杯，觉得自己已经拿捏了架构的真谛。但好日子没过两天，客服主管气冲冲地踢开你的门：“有个大客户投诉，他银行卡明明扣了 1 万块钱，但系统里根本没生成这笔订单！查！”你赶紧去查日志，瞬间冷汗直冒：扣款服务（生产者）确实发出了“生成订单”的消息，但订单服务（消费者）根本没收到！ 这条价值 1 万块钱的消息，就像石沉大海，在网络世界里人间蒸发了。这就是引入 MQ 必须付出的惨痛代价：薛定谔的消息。 今
2026-05-09 21:43:17
325
原创 穿透 MQ 专栏 (一)：【架构觉醒】服务器又被打挂了？用 MQ 筑起拦下十万并发的“三峡大坝”
在很多刚接触后端开发的同学眼里，所谓的“架构”，无非就是用 Spring Boot 写个 Controller，调一下 Service，最后用 MyBatis 把数据塞进 MySQL 里。只要在本地测试时，接口返回了，就觉得自己写出了改变世界的代码。直到有一天，公司搞了一场“一元秒杀”的营销活动。晚上 8 点活动刚上线，几十万用户瞬间涌入。你盯着监控屏幕，看着 Tomcat 的活跃线程数瞬间飙红，紧接着数据库连接池被打满，CPU 冲上 100%，最后整个服务在一片的哀嚎中彻底死机。
2026-05-09 21:18:01
385
原创 《穿透 MySQL 索引专栏（六）：从底层数据结构到千万级慢查询调优》
不需要显示调用，MySQL 会自动帮你加。当你对表执行 CRUD（增删改查）操作时，会自动加。
2026-05-08 17:32:14
481
原创 穿透 MySQL 索引专栏 (五)：【架构哲学】性能调优的终局之战：深分页灾难与千万级大表的索引设计原则
只把最后 10 条返回给你。为了 10 条数据，做 100 万次随机磁盘 I/O 的回表操作，数据库不死才怪。优化器这时候如果机灵点，甚至会直接放弃索引，去跑全表扫描，结果一样是死。
2026-05-08 17:32:02
185
原创 穿透 MySQL 索引专栏 (四)：【诊断利器】把 MySQL 的大脑剖开看：手把手教你读懂 EXPLAIN 这张“B超单”
前三篇文章，我们几乎把索引底层的物理结构和失效陷阱给扒了个底朝天。理论上，只要你遵守了“最左前缀法则”，避开了“函数刺客”和“隐式转换”，你的查询就应该快如闪电。你气急败坏地跑去查，发现 MySQL 竟然傲娇地把你的索引扔在一边，又去跑全表扫描了！“凭什么不走我的索引？！这就好比你生病了去医院，不能只靠猜。高级的数据库“老中医”从来不盲猜，他们会直接给 MySQL 拍一张“B 超单”—— EXPLAIN。今天，我们就把 MySQL 的大脑（优化器）剖开来看，带你读懂这张 B 超单上的每一个致命指标。
2026-05-07 14:15:07
242
原创 穿透 MySQL 索引专栏 (三)：【实战规则】明明建了索引却不上位？图解“最左前缀法则”与三大失效天坑
上一篇，我们手撕了“回表”这个性能黑洞，并祭出了“联合索引”这把屠龙刀来实现索引覆盖。很多同学学到这里，觉得自己已经天下无敌了。idx_a_b_c。结果代码一上线，数据库的 CPU 瞬间飙到 100%，系统直接挂掉。你跑去质问 DBA：“我明明建了联合索引，它为什么不用？为什么还要去全表扫描？！DBA 连眼皮都不抬，冷冷地吐出四个字：“其实，建了索引并不等于 MySQL 就一定会用。B+ 树有它自己极其严苛的物理排列规则。一旦你的 SQL 破坏了这个规则，这棵辛辛苦苦建好的树就会当场瘫痪。
2026-05-07 14:11:56
193
原创 穿透 MySQL 索引专栏 (二)：【核心机制】为什么 SELECT * 是性能杀手？扒开“回表”与“联合索引”的底裤
上一篇，我们在物理大地上算了一笔磁盘 I/O 的经济账，终于明白了为什么 MySQL 会把表的数据全部挂在“主键 B+ 树”的叶子节点上。此时，很多刚学完 B+ 树的同学会产生一种错觉：既然有了无敌的 B+ 树，那只要我在查询的字段上建了索引，查询速度就一定会像坐火箭一样快。如果你带着这种错觉去改线上代码，随手写下一句，并在name字段上建了索引。第二天，DBA（数据库管理员）大概率会拿着大刀来找你：“你写的破 SQL 把库拖垮了！你委屈地反驳：“我明明建了索引啊！
2026-05-06 22:37:22
237
原创 穿透 MySQL 索引专栏 (一)：【物理基石】别再死记 B+ 树了：从一次“全表扫描”看懂索引的物理本质
很多初学者在准备 MySQL 面试时，第一步都是去百度“什么是索引”，然后把“索引底层是 B+ 树”这句话死死刻在脑子里。但这其实是一种“黑盒思维”。如果面试官追问一句：“那为什么不能用红黑树？既然 B 树也能降低层数，为什么非要加个 plus 用 B+ 树？” 很多人瞬间就卡壳了。今天，咱们就把这些死记硬背的八股文全部扔掉。带你回到计算机最底层的物理世界，算一笔极其残酷的“经济账”。看看在海量数据面前，MySQL 到底是经历了怎样残酷的淘汰赛，才最终向 B+ 树低头的。
2026-05-06 22:35:18
437
原创 别干背八股文了：从一场“双十一秒杀”惨案，看懂 InnoDB 事务、锁与索引的底层齿轮
【案发现场】现在就剩最后 1 瓶茅台了。用户 B 和用户 C 在同一个毫秒，并发发起了扣库存请求。在程序眼里，他们俩看到的库存此刻都是 1。如果都执行成功，库存变成了 -1，这就叫超卖。【InnoDB 的暴力美学：各种极其刁钻的锁】高并发必生冲突，有冲突就必须上锁。精准打击的“行锁（Record Lock）”为了不让别人插队，当用户 B 的UPDATE语句一进去，InnoDB 就会在茅台的这行记录上挂一把锁（排他锁 X锁）。
2026-05-05 21:59:20
466
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人