背景 最近在做业务的时候，发现有很多地方需要将数据库查询出来的 list 转为 tree 结构，基于面向对象的思想，想着做成一个通用的工具类，使用泛型，然后首先想到的是使用递归，O(n * n) 后面觉得递归的传统方式，时间复杂度过高，基于此进行优化，想到了一个线性规划的方式，进行数据扁平化转为线性复杂度 O(N) 接口限定 定义一个 ItreeNode 接口，该接口主要用来子类实现，自己定义父节点的规则，只要使用方自己实现 parent 方法，自己定义父节点的规则，这样就无需 id 和 parentId 必须提前限制类型了， string 或者对象都可以作为获取父节点的基准 import java.util.List; /** * 通过实现该接口的子类 自己定义parent的规则 * @param <T> */ public interface ITreeNode<T> { T parent(); void setChildren(List<T> children); List<T> getChildren(); } 第一版 使用....

标题： 探索 Redis 与 @Transactional 注解的冲突之谜 正文： 前言 在我们的项目中，我们遇到了一个让人费解的生产环境问题：每天早上，当运营人员后台尝试创建新事件时，系统总是无法成功创建。经过重新启动相关微服务后，系统又能恢复正常运行，直到次日早上问题再次出现，又得重启服务。 初步调查 我们发现，问题出现在使用 Redis 生成唯一分布式 ID 的过程中。每天早上，Redis 的递增操作异常地返回了 null 值，导致后续流程中断。重新启动服务似乎是暂时的解决方法，但根本问题仍然悬而未决。 return redisTemplate.opsForValue().increment("count", 1); 深入探索 根据重启后就恢复正常，我们推测晚上执行了大量的 job，大量 Redis 连接未释放，当早上再来执行 Redis 操作时，执行失败。重启后，连接自动释放了。但是其他有使用到 Redis 的业务功能又是正常的，所以推测一的方向有问题，排除 。 通过查询 ```redisTemplate 递增的方法 increment` 源码注释, 发现事务&管道会返....

背景 公司有个主系统 A，这个系统将来用途作为 SaaS 服务系统，设计尽可能保持纯粹，不要引入过多的中间件技术 其下有 B,C 甚至未来还有多个子系统，现在的需求是需要当子系统 B,C 开启了某个配置，需要对接 A 系统，A 系统能够提供 B,C 系统的能力赋能，当 BC 断开配置，B,C 又是个纯粹可以单独运行的系统，某个系统不共用同一套数据，拥有自己的环境和数据，当子系统开启了配置，相关接口功能需要限制，由主系统提供能力，断开配置，A.B,C 三个系统能够独立运行 功能拆分 主系统: 对主系统相关的增量和全量接口数据进行同步传输：这里有两个关键点 有许多增量接口需要进行同步传输&&传输数据的逻辑不能影响原先的业务逻辑（通过 AOP 注解） 需要找到一个类型消息队列 mq 那种形势进行数据同步，A 系统数据发生改动子系统能够感知 但是这个系统不能引入过多的中间件，最终经过调研，选择使用了 Spring 的 STOMP 和 Spring event 事件实现一种伪消息队列 子系统： 子系统相关接口限制：通过 AOP 接口限制 子系统需要接收主系统的全量和增量数据 （S....

Spring 的依赖注入之谜：Spring 为何不拥抱静态字段 发表日期：2024 年 01 月 05 日 阅读时长：约 4 分钟 专栏标签：Spring 在 Spring 的世界里，每一个 bean 的成长都离不开一系列精心的培育过程。这个过程通常涵盖以下几个阶段： 反射孕育实例——通过反射机制创建 bean 实例。 属性的滋养——为 bean 填充属性，赋予其生机。 激活生命之火——初始化 bean，让其具备完整功能（可能伴随增强处理）。 谋划离别之时——注册 bean 的销毁方法，为其终结做好准备。 在这个生命周期中，“属性的滋养”阶段尤为关键，它正是在 populateBean 方法中得以实施。在这一过程中，除了通过 applyPropertyValues 方法直接填充属性外，大量的注入逻辑实际上是在 InstantiationAwareBeanPostProcessor 接口的 postProcessProperties 方法内实现的。这里对我们耳熟能详的 @Autowired 和 @Resource 注解进行了诠释。 protected void populateBean(....