weixin_43578751的博客

原创 STAR法则

STAR 法则的核心逻辑是 “从‘经历’到‘价值’的转化”—— 通过 “情境（为什么做）→任务（要做什么）→行动（怎么做）→结果（做成了什么）” 的链条，让你的经历不再是 “流水账”，而是能直接证明你能力的 “案例证据”。使用时需注意：每个环节环环相扣，且始终围绕 “你” 的角色与贡献展开。编辑分享在工作汇报中如何运用STAR法则突出个人贡献？提供一些STAR法则的实际应用案例如何使用STAR法则进行面试准备？

原创 使用 MQ 实现限时订单的方案对比

消息队列实现方式优势劣势适用场景Kafka无原生支持，需手动实现高吞吐量可靠性低，易出错不推荐RabbitMQ死信队列 + TTL实现简单，配置灵活延迟时间固定，不可动态修改延迟时间固定的场景RocketMQ原生延迟消息支持任意延迟时间，可靠性高需依赖 RocketMQ 环境所有限时订单场景，尤其是延迟时间灵活的业务实际开发中，推荐优先选择 RocketMQ 的原生延迟消息功能，既能保证可靠性，又能简化开发流程。

原创 消息中间件选型分析：RabbitMQ vs RocketMQ vs Kafka

维度RabbitMQKafkaRocketMQ开发友好性❌ 复杂（需懂 AMQP）✅ 简单（Topic 模型）✅ 简单（Spring 风格）部署难度❌ 高（依赖 Erlang）⚠️ 中等✅ 低（JDK 即可）吞吐性能⚠️ 一般✅ 极高✅ 高功能完整性⚠️ 一般❌ 较弱✅ 完整集群扩展性❌ 弱✅ 强✅ 强适用场景老系统、多语言大数据、流处理高并发、通用业务随着技术发展，消息中间件已从“能用”走向“好用、易维护、可扩展”。

原创 Disruptor介绍

指标Disruptor 表现吞吐量> 100 万事件/秒（单生产者单消费者）延迟平均 < 1 微秒，P99 < 10 微秒CPU 利用率高效，避免忙等GC 压力极低（对象复用）线程安全无锁，高并发下稳定在高并发下吞吐通常只有几万/秒，延迟在毫秒级。它不是一个通用消息队列，而是一个为极致性能而生的内存事件管道。对硬件的深刻理解（CPU 缓存、内存模型）；对并发的精细控制（无锁、CAS、等待策略）；对 GC 的极致规避（对象复用、预分配）；当你需要在。

原创 DisRuptor在单体项目中的应用

项目说明起因安全策略禁用 XML，导致 Log4j2 无法使用结果封装日志模块失效，需临时替代方案决策放弃完整日志功能，仅保留“日志落库”核心能力技术选型使用Disruptor实现高性能异步写入优势高吞吐、低延迟、无锁、不阻塞业务线程代价损失日志灵活性，需自行维护事件模型未来方向迁移至 Logback 或重构日志架构✅Disruptor 在此场景下是合理且高效的选择，尤其适合“高并发 + 异步持久化”的临时救急方案。

原创 分布式事务之Seata与RocketMQ

核心区别SeataRocketMQ“管什么”管 “多服务多数据源的事务协调”管 “本地事务与消息发送的一致性”“怎么用”需部署独立协调器，支持多种事务模式复用 MQ，仅需调用事务消息 API“适合谁”复杂多服务事务、非 SQL 场景、强一致性需求简单单事务 + 多通知、已有 MQ、高并发选型口诀多服务多库用 Seata，单事务多通知用 RocketMQ；非 SQL 场景用 Seata TCC，已有 MQ 不用额外加 Seata。

原创 Spring事务源码

阶段核心机制启动导入和Advisor代理创建为带的 Bean 创建代理（JDK/CGLIB）方法调用代理触发事务开启调用线程绑定使用存储连接DAO 访问等从获取当前事务连接自调用失效绕过代理，无法拦截🔁一句话总结：Spring 事务 =AOP 动态代理拦截的状态管理。理解这三者如何协同工作，就真正掌握了 Spring 事务的“内核”。

原创 多线程 + 事务传播误用导致的问题

/ 外层：不加事务，或只用于非核心操作// 内层：每个任务使用 REQUIRES_NEW});核心思想：在多线程异步处理中，避免共享事务上下文，使用实现任务级别的事务隔离与可靠性，是 SaaS 系统中高并发、高可用场景的推荐实践。

原创 Typra高亮配置操作指南

Typra高亮配置操作指南

原创 拓扑排序算法在工作流审批轨迹预测优化中的应用

通过拓扑排序算法对工作流中的任务依赖关系进行处理，如果最终得到的拓扑排序结果中的任务数量与工作流中总任务数量不一致，就说明工作流中存在循环依赖，该工作流不合法；​ 通过数学建模就可以发现，在同意审批参数中，我们的工作流就是一个特殊的有向无环图，入度为0的节点只有一个工作流定义中的开始节点、出度为0的节点也只有一个工作流结束节点。在 OA 系统中，用户可以自定义各种工作流。虽然拓扑排序得到的是一个线性序列，但可以根据任务之间的依赖关系，找出不相互依赖的任务，将它们并行执行，从而提高 OA 工作流的执行效率。

原创 SpringAop关键接口`@EnableAspectJAutoProxy`

的源码非常简洁，核心是通过导入：作用：开启 Spring 对注解切面的支持，使、等通知注解生效。关键参数：：默认，表示优先使用 JDK 动态代理（目标类需实现接口）；设为时，强制使用 CGLIB 代理（通过继承目标类）。：默认；设为时，代理对象会被存入（可通过获取），解决 “目标方法自调用无法被增强” 的问题。二、注册的作用是触发的逻辑，其核心功能是向 Spring 容器注册：：向容器注册的 BeanDefinition，确保其作为 Bean 被实例化。后续逻辑将的属性（、）设置

原创 SpringAop中Advisor总结

Advisor。

原创 SpringAop源码中的装配器模式

装饰器模式的优点灵活性高：可以动态地给对象添加功能，并且可以随意组合不同的装饰器遵循开闭原则：不需要修改现有代码就能添加新的装饰器替代继承：通过组合而非继承的方式扩展功能，避免了类爆炸问题功能单一：每个装饰器只负责添加一种功能，符合单一职责原则这种模式在 Java IO 库中也有广泛应用，例如等都是装饰器模式的实现。

原创 Spring Aop中切面Aspect与Advisor

切面（Aspect）” 是 AOP 的核心理论概念，代表跨类关注点的模块化；“Advisor” 是 Spring AOP 中对 “切面” 的一种具体实现，是 “切点 + 通知” 的封装，属于 “切面” 的子集或特定形式。因此，不能直接说 “Advisor 就是 AOP 的切面”，但可以说 “Advisor 是 Spring AOP 中实现切面功能的一种方式”。

原创 Spring AOP 的拦截器链

proceed()方法本身不区分 “前置” 或 “后置” 拦截器，它仅负责驱动拦截器链的递归执行（按顺序触发下一个拦截器）。拦截器是 “前置” 还是 “后置”，由其invoke()方法中 **proceed()前置拦截器：先执行自身逻辑，再调用proceed()（递归）。后置拦截器：先调用proceed()（递归），再执行自身逻辑。这种设计通过 “责任链模式 + 递归”，将不同类型的增强逻辑按预定顺序串联，最终实现了 AOP 中横切关注点的灵活织入。

原创 Spring IOC与Aop之间的代码串联

2. 阶段：AOP 的准备工作（收集切面信息）执行位置：在 内部的 方法中，初始化方法（、）执行之前。核心操作：目的：提前完成切面筛选，避免无效代理，同时为循环依赖场景下的早期代理引用提供支持。执行位置：在 内部的 方法中，初始化方法（、）执行之后。核心操作：目的：在 Bean 完成所有初始化逻辑后，通过代理对象将切面通知（如 、）织入目标方法。plaintex

原创 Spring Bean生命周期值doCreateBean源码

if (!try {// 应用MergedBeanDefinitionPostProcessor处理器// 标记为已处理，避免重复执行核心动作：调用接口的方法，允许对合并后的 Bean 定义（）进行修改。典型应用：Spring 内部的会在这里解析@Autowired@Value等注解的元数据，记录需要注入的属性信息。实例化（创建原始对象）→ 处理合并定义 → 提前暴露单例（解决循环依赖）→ 属性填充（依赖注入）→ 初始化（包括 Aware 回调、初始化方法、后处理器）→ 校验循环依赖一致性。

原创 Spring Bean生命周期InstantiationAwareBeanPostProcessor接口的执行位置

结合你提供的代码片段，// 1. 实例化 Bean（createBeanInstance）// 【注意】postProcessBeforeInstantiation 在这一步之前执行（doCreateBean 外部）// 2. 处理合并的 Bean 定义（与 InstantiationAwareBeanPostProcessor 无关）// 3. 提前暴露单例（解决循环依赖）// 4. 初始化 Bean 实例try {

原创 Spring 循环依赖的理解

循环依赖的核心是 “相互引用导致的初始化阻塞”，解决的关键是 “提前暴露半成品对象的引用”。非 Spring 场景可通过一级缓存手动暴露半成品；Spring 通过三级缓存（尤其是三级缓存处理 AOP 代理）解决单例 Bean 的循环依赖。仅单例 Bean 的字段 /setter 注入支持循环依赖；原型、构造器注入等场景不支持或需特殊处理。

原创 Java 8 接口默认方法与Adapter适配器模式

是适配器模式的应用：通过一个中间类适配接口，简化接口的实现。Java 8 接口默认方法不是适配器模式，它是接口自身的功能增强，通过默认实现解决接口升级的兼容性问题，从而替代了上述适配器类的作用。

原创 Springboot微服务nacos注册异常记录

最初面对报错时的茫然无措，很容易让人陷入 “源码崇拜” 的误区 —— 对着 Nacos 故障转移逻辑逐行拆解，熬夜钻研到凌晨，却始终在复杂的源码森林里兜圈子，身心俱疲之际反而离真相越来越远。直到跳出细节看全局，才猛然意识到：微服务的核心依赖 SpringWeb 被误删，直接导致 Nacos 客户端失去了启动基础，连注册的 “入场券” 都没拿到，自然会触发本地缓存的故障转移机制。一开始问题产生的原因是我的微服务程序整理依赖，把一部分依赖放在公共模块下，导致我的项目无法注册到nacos上。

原创 SpringBoot 的工作原理

SpringBoot 的工作原理核心围绕 “自动装配” 展开，而注解和方法是实现这一原理的两大核心支柱。它们的协同工作让 SpringBoot 实现了 “零配置” 或 “极简配置” 就能快速启动一个生产级应用。是一个复合注解，它整合了三个核心注解的功能，是 SpringBoot 应用的 “入口标识”：自动装配的本质是：SpringBoot 根据类路径下的依赖（JAR 包），自动推断并配置所需的 Bean，无需手动编写 XML 或 JavaConfig。其核心流程如下：方法是 SpringBoot 应用的启动

原创 @Autowire跟@Resource的注解混用造成的惨案

特性@Autowired@Resource来源Spring 框架Java 标准库（JSR-250）注入依据先按类型，后按名称（需配合@Qualifier先按名称，后按类型（可通过name指定）支持的注入位置字段、方法、构造器、参数字段、方法（不支持构造器 / 参数）是否允许为 null支持不直接支持（需结合@NullableSpring 特性兼容性好（支持@Primary@Qualifier等）一般（Java 标准，弱依赖 Spring）

原创 Java基础-注解

注解是 Java 中一种强大的元数据机制，它通过 “标记 + 解析” 的方式，为代码提供灵活的扩展能力。理解注解的核心是：它不直接参与业务逻辑，而是作为 “桥梁” 连接代码与工具 / 框架，让外部系统根据注解信息做出相应处理。在实际开发中，合理使用注解（结合反射或处理器）能显著提升代码的简洁性和可扩展性。

原创 多线程及高并发:wait()和notify()

方法是基于对象的监视器（monitor）机制实现的。每个 Java 对象都可以关联一个监视器，当一个线程进入。同步代码块或同步方法时，它会获取该对象的监视器锁，只有持有该对象监视器锁的线程才能调用该对象的。方法的对象必须是同步代码块或同步方法里的锁对象，否则会抛出。在这个正确的示例中，同步代码块使用的锁对象和调用。在上述代码中，同步代码块使用的锁对象是。，这样就符合规则，不会抛出异常。异常，因为当前线程没有持有。

原创 【@EnableDiscoveryClient注解功能逻辑】

@EnableDiscoveryClient是一个组合注解，它借助@Import注解导入了类，这个类承担着自动配置服务发现客户端的关键任务。

原创 WSL docker安装oracle11g

docker安装Oracle11g实现数据库的部署

原创 Java观察者设计模式在项目中的应用

设计模式在实际项目中的应用

原创 SpringBeanUtils

原创 Java Jar包替换

使用WinRAR解压软件打开打好的Jar包。

原创 IDEA2023 配置使用Docker

我们写的代码会接触到好几个环境：开发环境、测试环境以及生产环境等等。多种环境去部署同一份代码，由于环境原因往往会出现**软件跨环境迁移的问题**，针对这种问题Docker提供了一个完美的解决方案，统一集成容器部署。其次容器性能开销极低的特点，配上Idea的编译，完美塑造后端程序员开发环境。

原创 Linux查看log日志命令总结

企业项目都运行在Linux环境，熟悉Linux环境下的日志查看结合远程调试端口及时排查程序bug，是后端程序员需掌握的必备技能。