- 博客(135)
- 收藏
- 关注
RSS订阅原创 Spring Boot 本质揭秘：约定优于配置 + 自动装配
AOP 是手术刀，代理是手。用错手，刀再锋利也切不准。接口类 → JDK Proxy，简单高效；无接口类 → CGLIB，通用灵活；混用项目 → proxyTargetClass=true一劳永逸；永远别忘：自调用绕过代理、final 无法增强。一句话收尾：“懂得代理之别，才算真正入门 Spring AOP 的底层世界。
2025-10-22 15:23:00
646
原创 从代理到切面：Spring AOP 的本质与应用场景解析
把横切逻辑抽离出来，让业务代码更纯粹；用代理机制无侵入织入逻辑；让日志、权限、事务、缓存都能“声明即用”。一句话记住：“AOP 让你从写代码的人，变成编织系统行为的人。
2025-10-22 14:10:46
377
原创 面试必问：Spring Bean 的作用域类型有多少种？
除了这五种内置的作用域，Spring 还允许你注册自定义 Scope。比如你想让某个 Bean 在“线程”级别隔离，就可以自己定义一个@Override@Override@Bean@Component🎯 这样每个线程都会维护自己的一份 Bean 实例——非常适合异步任务或线程隔离场景。很多人理解 Bean 生命周期，却忽略了“它在哪活着”这件事。Spring 的 Scope 就像给 Bean 发的“居住证”，决定了它在哪被创建、由谁销毁、能被谁看到。
2025-10-22 13:29:23
387
原创 IOC 容器的进化：ApplicationContext 在 Spring 中的核心地位
如果说 BeanFactory 是“造 Bean 的机器”，那 ApplicationContext 就是“让整个应用活起来的生态系统”。生命周期管理者事件调度中心国际化桥梁AOP 与事务的激活器Spring Boot 自动配置的基石“ApplicationContext 是 Spring 的心脏，它让 IoC 从‘能用’变成‘能活’。
2025-10-22 10:06:50
815
原创 你以为 Bean 只是 new 出来？Spring BeanFactory 背后的秘密让人惊讶
你写的每一个 Bean、用的每一个@Autowired、加的每一个@Component背后都是 BeanFactory 在默默操盘。它是整个 IoC 的基础接口，是容器的“发动机”；是它的“整车版本”，负责更多高级功能；理解它的工作流程，是搞懂 Bean 生命周期、依赖注入和 AOP 的关键前提。“BeanFactory 不只是一个 Map，它是 Spring 世界的心脏。Bean 的一生，都在它的调度之中。
2025-10-21 16:45:31
356
原创 项目写得再多也没用！Spring Bean 的核心概念要是没懂，迟早踩坑
它不仅是“被托管的对象”，更是容器与业务代码的连接点；它的生命周期决定了依赖注入、AOP、事务能否正确工作；它的作用域影响着实例行为和线程安全；它的管理方式，决定了你的代码是“Spring 风格”还是“面向 new 风格”。“Bean 不是你 new 出来的对象，而是 Spring 世界的公民。你要理解它的一生，才能真正理解 Spring。
2025-10-21 15:44:00
358
原创 定时任务写错姿势？@Scheduled 才是 Spring 官方推荐方案
✅ 用@Scheduled取代手动线程管理，让调度与 Spring 生命周期融为一体✅ 用fixedRatefixedDelaycron灵活适配各种业务场景✅ 配合配置文件、异步、分布式锁，让任务真正上生产级“你可以不用@Scheduled，但你错过的不是一行注解，而是一整套官方推荐的调度体系。
2025-10-21 13:57:36
984
原创 当容器里有多个 Bean，@Qualifier 如何精准定位？
Autowired是‘我有很多朋友’；@Qualifier是‘我只要这个朋友’。在多实现场景下，不加@Qualifier就像在地铁口喊“张三”一样模糊。Spring 不会猜你要哪个，实现类越多，风险越大。用好这把“点名器”，才能让注入既精准又优雅。
2025-10-20 15:18:07
601
原创 还在写繁琐监听器？Spring @EventListener 注解让你代码瞬间简化
在现代 Spring 项目里，它让监听逻辑回归业务本身，不再被接口和注册束缚；它天然支持条件过滤和异步执行，性能与可维护性兼得；它让我们能轻松实现事件驱动架构（EDA），系统扩展性更强。“事件驱动 + @EventListener = 更优雅的解耦方式。你写的就不再是监听器，而是一个个“有明确意图的事件响应点”。
2025-10-17 17:15:58
837
原创 用错注入方式？你的代码可能早就埋下隐患
注入方式是“设计决策”，不是“写法口味”。构造器注入让依赖显式、对象不可变、测试友好；Setter 只给真正可选的依赖；字段注入慎用。今天省下的一行new，可能是明天省下的一晚通宵。
2025-10-17 15:45:14
393
原创 Spring 创建 Bean 的多种方式对比与最佳实践
怎么用@Component特点Bean 的“生产逻辑”可编程化，适合复杂/延迟/池化创建。。便于封装复杂 SDK 实例化、动态代理实例、框架级 Bean。何时选：构造过程复杂、需要“拿结果不是拿工厂”的场景。把“谁创建、何时创建、在哪创建、如何销毁”说清楚，就是 Bean 策略的全部。业务常态化用@Component；第三方与精细控制用@Bean；复杂构造上；模块化上@Import；其余按场景增量选择。选对方式，系统启动快、结构清晰、扩展成本更低。
2025-10-17 14:58:27
849
原创 对象居然不用自己创建？Spring 依赖注入机制的真相惊呆了！
当你开始习惯用依赖注入的时候，你就从“写代码”跨进了“设计系统”的门槛。业务逻辑和对象创建分离扩展和替换几乎不需要改动代码单元测试不再依赖真实实现依赖注入不是省事的语法糖，而是让代码变得可维护、可测试、可扩展的根本武器。
2025-10-17 13:33:40
747
原创 从 AOP 到代理：Spring 事务注解是如何生效的？
很多人第一次用 Spring 事务时，都会掉进“注解即万能”的陷阱里。注解只是声明意图AOP 才是织入逻辑的入口事务管理器才是落地执行者所以，会用是入门，会解释它为什么生效，才是你和别人拉开差距的地方。下次再被问到“Spring 事务是怎么实现的”，别再只说“靠注解”，说出“代理、AOP、事务管理器”这三件套，面试官会对你另眼相看。
2025-10-16 17:29:30
916
原创 面试高频：Spring 事务传播行为的核心价值是什么？
传播行为（Propagation）决定了一个方法在被调用时，事务该怎么处理：是加入现有事务？新开一个？还是干脆不参加？Spring 提供了 7 种常见的传播行为，默认是REQUIRED如果你不写，默认就是它。很多人把事务传播当成“配置选项”，但在我看来，它更像是事务的“语言”：它决定了事务之间是共进退，还是各自为战；是强绑定，还是弱关联。如果说隔离级别解决的是“一个事务内部的数据安全”，那传播行为解决的就是“多个事务之间的协作逻辑”。
2025-10-16 15:44:57
335
原创 数据一致性全靠它！Spring 事务传播行为没搞懂=大坑
如果你现在还在犹豫传播行为到底怎么选，给自己一个简单的口径：要对数据强一致的部分，用同一个事务把相关调用绑死；要对外部系统或长时间任务进行解耦，使用明确的独立边界并配好补偿逻辑。别让一个小小的传播选择，把后续几十行代码的正确性全都打碎。愿你我都能在复杂的分布式场景里，靠这点“边界感”活成稳稳的老程序员。
2025-10-16 14:58:09
245
原创 从 READ_UNCOMMITTED 到 SERIALIZABLE：Spring 事务隔离级别全解析
一头是数据一致性一头是系统性能。你越往一致性那头靠，性能就越低；你越追求性能，风险就越高。所以，选什么隔离级别从来不是背诵题，而是业务决策。支付系统、金融结算这类强一致性场景，可能会用到甚至；而高吞吐的日志分析、推荐系统，也完全够用。记住一句话：事务隔离没有“最好”，只有“最合适”。
2025-10-16 13:59:58
543
原创 别再乱用了！Spring AOP 与 AspectJ 的区别比你想的复杂
AOP（Aspect-Oriented Programming，面向切面编程）说白了就是——在不修改原始代码的情况下，为它们“织入”额外的行为，比如日志、事务、安全校验、监控埋点。在方法执行前后自动插入逻辑（前置 / 后置通知）在抛出异常时做统一处理在不改业务代码的前提下，实现横切关注点而 Spring AOP 和 AspectJ，正是实现这一切的两种“不同武功秘籍”。
2025-10-15 17:21:45
465
原创 面试官最爱刁难：Spring 框架里到底用了多少经典设计模式？
当年我以为“设计模式”只是面试背的八股文，Spring 用起来也不需要懂这些。现在回头看，Spring 就像是一本活着的《设计模式 GOF》：每一种模式都不是纸上谈兵，而是有血有肉地活在框架里。所以，下次再有人问你“Spring 用了哪些设计模式”，别只说“单例和工厂”了。真正的高手，早已把设计模式变成了写代码的肌肉记忆。
2025-10-15 16:18:58
712
原创 你以为只是名字不同？Spring 三大注解的真正差别曝光
要不要我下一篇写《@Configuration 和 @Bean 的底层区别与最佳实践》，它和这篇一样，是面试高频“表面一样但底层差很远”的注解对比题。从容器扫描到异常翻译，从层级划分到 AOP 切面，它们早已超越“换个壳”的层面，是整个分层架构协作的基础。后来踩了无数坑，我才明白：这些注解，虽然“看起来都能扫进容器”，但背后的语义和用途，可一点都不一样。结果第一次面试被问到“这三个注解有什么本质不同？”我支支吾吾：“呃……，日志埋点用注解扫描也失效，AOP 切面拦不住，异常也不再统一。
2025-10-15 14:21:55
671
原创 Lazy能否有效解决循环依赖？答案比你想的复杂
记得有一次项目重构，刚好碰上了两个Bean「互相喜欢」的情境。A 里面要用 B，B 里面又要用 A。Spring 启动直接报错，像极了早恋被班主任逮住。不是灵丹妙药，是保姆级平衡剂，有用时能帮买瓶可乐，没用的时候就像一瓶开了盖的雪碧——气全没了。能解一时之急，解不了结构性的矛盾。写代码嘛，咱既要有巧劲，也要有狠劲。B里面也来一手，但是看到这里你可能都能猜到，心态飘了。当然，身为不服输的程序猿，怎么可能直接认栽！，美滋滋地以为一切OK。说真的，当时我信了半截……聊到最后，如果你正撸着咖啡想着用。
2025-10-14 13:25:52
396
原创 从构造器注入到 setter：Spring 循环依赖的常见场景解析
循环依赖就是 Spring 世界里的“死循环副本”，新手第一次遇到时总是手忙脚乱，老手见得多了就知道，有时候不是 Spring 不行，而是设计得太绕。构造器注入容易出事，Setter 注入能救大多数场景，@Lazy 是急救药，但最好的解法永远是重构。
2025-10-14 09:28:35
531
原创 三级缓存揭秘：Spring 如何优雅地处理循环依赖问题
咱们打断点调了又调，才发现每当 A、B 互相依赖时，Spring 就提前把工厂对象注册进三级缓存。A 注入 B 时（一脸无助），发现自己不在成品区，索性先暴露个“毛坯版”A。有一次，我一不小心写了俩服务，A 里注入了 B，B 里又非要注入回 A。说实话，第一次点进 Spring 源码看的时候，我全程黑人问号脸。最后，“收个尾巴”：你要跟循环依赖过不去，Spring就跟你和解；如果非要描述踩坑瞬间，就是各种“BeanCurrentlyInCreationException”的红色大字，佛系劝退新手。
2025-10-13 17:22:30
354
原创 为什么几乎所有 Java 项目都离不开 IoC？Spring 控制反转的优势惊人！
你可以把 IoC 想象成 Java 中的“外包”。对象也知道累，new 来 new 去太忙了。IoC 就像说：“兄弟，别自己找对象了，我来管，缺啥告诉我。到处 new，代码像粽子，耦合得紧巴巴的。“我只要说需求，不用管怎么造、谁来造。”，大佬范儿有了。Java 项目搞大点，模块一多，一改就一身汗。IoC 这时候就是你的超人队友。
2025-10-13 16:39:14
382
原创 事务崩了别怪数据库！三大核心要素没掌握才是根本原因
哈哈，他这口气像极了觉得自己一点问题都没有，锅都是 MySQL 的锅。踩坑不可怕，搞明白才是大佬。下一次，事务失效不要再冤枉你家数据库，先照照镜子想想，是不是自己三大要素没掌握。槽点来了，所以说“抛异常自动回滚”，你确定吗？说真的，每次上线修 Bug 遇到“事务失效”这四个字，我都想立马上楼顶冷静一下。数据库被程序员骂了无数次，但不少时候还真不能怪它——大多数雷，都是我们自己埋下的。所以别再张口闭口“数据库背锅，MySQL太坑”，其实各种事务悬案，80%是自己代码写崩的。”——好家伙，这就是故事的开始。
2025-10-13 15:10:15
377
原创 你以为自动开启？Spring 事务支持其实还需要这几步！
今天就聊一聊，这个看似贴心，实则有点坑的Spring事务自动支持，顺便聊点亲身“翻车”经历。Spring事务能省心也能坑人，关键细节别假设“自动就给你安排清楚”。多踩几坑就记住了——写代码是自己的，掉进坑里只能自己爬，兄弟们共勉！，结果B挂了，事务没回滚。Spring事务代理是基于AOP做的，自己call自己直接调用了原生方法，代理不参与，事务“不感知”。初入Spring的时候，官网上的例子让我信誓旦旦。不聊了，我去修bug了 🤦♂️。手动抛了也不一定行。后来，老伙计们交了我几招。这，就是我的全部防线。
2025-10-13 14:40:28
311
原创 多环境配置利器：@Profile 在 Spring 项目中的实战价值
上半部分是 dev 环境，下半部分是 prod，Spring 会自动根据激活的 profile 选对的那一段。开发一个配置，测试一个配置，上线又要改一遍……直到我第一次在凌晨两点把测试环境的配置打进了生产，运维同事脸都绿了——我才痛定思痛，开始认真研究起。有时候忘记改，有时候改错地方，部署之后不是连不上数据库，就是把测试数据刷进了线上，整个项目险些扑街。说实话，刚开始写 Spring 项目的时候，我也跟大多数人一样，嫌“多环境配置”就是麻烦：！，你以为是缩写，Spring 不认识你，直接走默认配置。
2025-10-11 13:29:08
548
原创 从配置文件到 SpEL 表达式：@Value 在 Spring 中到底能做什么？
其实我当时也很天真，以为这玩意不过就是绑定个配置参数，小 case。直到有天，老大让我搞个动态规则调整，还特意补了句：“@Value 不是还能解析表达式么？话说回来，说了这么多，也就是想把这些踩坑血泪史，悄悄地埋进博客里当“定心丸”。有配置就填，没配置就呵呵，靠的就是 application.properties？吐槽归吐槽，@Value 这东西只要用对场合，确实是 Spring 家的一把瑞士军刀。其实这些坑，真心有点冷酷，基本上属于“用起来顺手，玩花了就翻车”我承认，最早接触 Spring 的时候，对。
2025-10-09 15:11:06
237
原创 不加 @Primary？Spring 自动装配时可能直接报错！
说来惭愧，前两天在写一个 Spring Boot 的小模块，自以为稳如老狗，结果居然在自动装配的时候遇到了个小坑，令人头大。事情经过非常“程序员”：本来想着加几个接口实现，被 Spring 自动注入一把梭，谁能想到因为懒得加。给删了，想说“反正业务单一，应该没啥影响吧”。接着重启服务，结果后台直接报错——Spring 提示我：“哥们，你这注入有歧义啊，我可不知道要选哪一个！，分分钟让你怀疑人生，但加上以后，你会发现世界都安静了。不过，要我说，这种骚操作还是别轻易用，能偷懒就用。都习惯成自然了，哪想多了。
2025-10-09 10:57:45
294
原创 新手最容易忽略！Spring 自动装配的 5 种方式全解析
初入 Spring 世界的那会儿，我像拿着魔法棒的小巫师，对什么都感兴趣，尤其是“自动装配”这个听起来特别高深的词。可谁能想到，自动装配的“打开姿势”居然有那么多种，每个都不太一样，一不小心还会踩雷。今天就来聊聊，这 5 种常见的 Spring 自动装配方式，我是怎么踩坑、摸索、顿悟一路走来的。内部优先按名字找，某次 copy 代码手滑拼了个“fooSercice”（没错，我拼错了），编译 OK，但运行就是注不进来。这世界，唯有 Spring 的装配方式，能让你短短两行代码，体会“天堂地狱一线间”。
2025-09-30 16:01:17
291
原创 事务没生效还以为成功了？Spring 事务失效的雷区你中招了吗？
说到底，Spring 事务这玩意儿，看起来像金钟罩，实际上挺玻璃心的。你 bean 配的不对，用了接口却搞 CGLIB，或者没接口强行用 JDK Proxy，Spring 事务直接说：你高兴就好，我给你个假笑。，就像用了金箍棒，后端没人搞得定我数据了。Spring 事务有点像「旁观者清」，得靠“代理”来戴帽子，自己 call 自己，Spring 懒得理你。所以，今天给大家聊聊几种最容易踩的「Spring 事务是一片滩涂」的时刻。），Spring 默默微笑，数据不 rollback，你看着办吧！
2025-09-30 10:03:48
615
原创 从 IOC 到多线程：Spring 单例 Bean 的并发安全性全解析
Spring 单例 Bean 的并发安全性，说白了就是一句话：Spring 管你“有没有”，不管你“安不安全”。想偷懒：尽量写无状态 Bean。想稳妥：用并发工具类兜底。想装逼：顺手再抛出 IOC + AOP 的设计哲学，面试官立刻觉得你“格局打开了”。等你踩过一次“计数器翻车”的坑，就再也不会天真地以为“单例=线程安全”了。
2025-09-29 17:17:20
600
原创 事务嵌套场景必问：Spring 传播机制如何真正发挥作用？
事务这玩意，看着就几个注解属性，真到生产环境里就是个大型翻车现场。传播机制的几个关键点，面试和实战都能用得上：REQUIRED：默认选手，外有就加入，没就开新。REQUIRES_NEW：真·新开事务，但必须通过 Spring 代理调用，异常别忘了 catch。NESTED：玩 savepoint 的，支持局部回滚，前提是底层数据库和事务管理器撑得住。SUPPORTS / MANDATORY / NEVER：这仨平时少用，但面试官爱问，知道就好。
2025-09-29 16:32:28
942
原创 别乱用！线程池拒绝策略选错，系统可能直接崩！
线程池策略是个“小配置”，但用错了就是定时炸弹。配置这些细节，一定要和业务场景连起来想。别像我，被一个 abort 弹窗教育做人。行吧，今天 rant 到这，溜了——得继续填昨天那些“被拒绝”的数据坑去。别乱用默认值，你的锅盘不一定结实！
2025-09-29 15:24:26
260
原创 颠覆认知！synchronized 的轻量级锁竟然还会自旋？
说起来，本来我一直用了十几年的 synchronized，早就当它透明胶带：粘一粘，线程安全就稳了。从此，每次写 synchronized，总感觉背后有个 JVM 小哥在我耳边说：“兄dei，放心，让我帮你兜一把！我有次手贱把 synchronized 放到了很大的代码块上，结果 CPU 飙升，线程堆积，“自旋”变成了“原地画圆”（线程：我到底在等什么？来吧，今天聊点八卦，揭秘一下线程池底下那些“不为人知的故事”。一定得追，毕竟咱每加一个线程，都是在“烧钱”（内存，切换开销什么的），池子大，责任也大。
2025-09-29 13:57:25
255
原创 Java线程池那些坑：我与线程池的恩怨情仇
Java线程池挺像“打怪刷副本”——boss很多，组队分工。但别太迷信“大锅饭”：参数得自己掌控，池子别乱用。线程池（ThreadPool），顾名思义，就是线程大本营。Too young，too naive，躺平的你总有一天要被线程数爆表狠狠教育。百万请求，百万线程，服务器CPU和内存都当我透明的……那会儿我还清纯，Ctrl+C、Ctrl+V贴了段Spring教程里的套路：。你以为“线程”分分钟搞定，不就是。听起来跟共享单车差不多：车永远不够，但调度妙，骑到就有。后来明白，线程池四个关键参数：。
2025-09-29 09:26:28
452
原创 锁升级到底能不能“退烧”？synchronized 释放后状态解析
理想画面里，synchronized、ReentrantLock 这些锁随用随走，锁状态自己聪明得很，锁住时候用升级，没人抢争马上退烧，“降级”，多么体贴——但事实真这样吗？说出来你别笑，Java 的 synchronized 锁升级过程，那真是比宿舍热水器的档位还复杂点。但真相就像“前任还会回来吗”这个鸡汤问题，理想很丰满，现实骨架瘦。只要晋升过一次，哪怕后面没人抢，大哥级别的“重量级锁”标签就一直贴在对象头上了。直到翻了 JVM 源码（狗头），结局彻底认清了：兄弟，认命吧，没降级这回事！
2025-09-28 16:59:17
918
原创 颠覆认知！synchronized 的轻量级锁竟然还会自旋？
说起来，本来我一直用了十几年的 synchronized，早就当它透明胶带：粘一粘，线程安全就稳了。从此，每次写 synchronized，总感觉背后有个 JVM 小哥在我耳边说：“兄dei，放心，让我帮你兜一把！换句话说，JVM 在“阻塞”之前还会帮你“抢红包”兜底几下，说不定你卡个 1ms 就能等到 CPU 空。我有次手贱把 synchronized 放到了很大的代码块上，结果 CPU 飙升，线程堆积，“自旋”变成了“原地画圆”（线程：我到底在等什么？你没看错，真·自旋，出现在了轻量级锁阶段。
2025-09-28 15:48:23
408
原创 从对象头到内存屏障：synchronized 如何实现原子性、可见性与有序性
而且，可见性靠的不是你开的锁，而是加解锁那一瞬间的【内存屏障】。其实是我误会了锁的作用域——要命的时候发现，锁的是堆上的对象，对象头一切OK，但如果你给别的对象加锁，只保证持有锁的那段代码安全，可视野之外满是危险。有时候你写 Java，总觉得自己像个江湖上的镖师，左挡右护，不就想保证点安全么？最后，面试遇到“三大特性”，别只会嘴巴说“原子性、可见性、有序性好呀”——背后原理、对象头里藏的秘密，你得有点小故事，才敢拍胸脯说“我懂点门道”！谁说锁一定烂，关键看你会不会用，用得巧，JVM也会帮你省事。
2025-09-28 14:40:42
899
原创 多线程乱成一锅粥？教你把线程按顺序乖乖排队！
你有没有那种很奇怪的时刻：代码明明一切正常，编译都OK，跑着跑着，忽然蹦出来个叛徒，报了个“你并发修改啦！说起来，还有一种阴间用法：“先收集要删的元素，循环结束后再统一remove”。你别看ArrayList的体面，其实心里住着个会记仇的小本本：只要你每增删一次，它modCount自增一次。每次 next() 都偷看一下自己记的小本本，和外面对比一下，不一样就：嘿，抓住你了！其实，这种大坑就像地铁上的小偷，看不见、摸不着，一不小心钱包（程序）就没了。印象里 Java 的集合都很友善，管你怎折腾，顶多。
2025-09-26 16:58:08
520
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人