<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[eclipseC的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/eclipseC</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; eclipseC]]></copyright><item><title><![CDATA[Spring事务实现原理深度解析：从源码到架构全面剖析]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/154744778</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/154744778</guid><author>eclipseC</author><pubDate>Wed, 12 Nov 2025 17:32:26 +0800</pubDate><description><![CDATA[Spring事务通过AOP代理、事务管理器、同步机制等组件提供了强大而灵活的事务管理能力。本文将重点剖析事务传播机制的实现原理，包括事务管理器的架构、AOP代理原理、事务同步机制、传播行为实现细节等核心概念。Spring事务管理建立在三个核心接口之上，这些接口构成了整个事务管理体系的抽象层：
1.2 事务管理器实现层次结构
Spring提供了多种事务管理器实现，形成了清晰的继承体系：
1.3 数据源事务管理器实现
是Spring中最常用的事务管理器实现，它管理JDBC连接的事务：
2. Spring事务AO]]></description><category></category></item><item><title><![CDATA[并发：AQS源码解析]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/151721789</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/151721789</guid><author>eclipseC</author><pubDate>Mon, 15 Sep 2025 17:05:09 +0800</pubDate><description><![CDATA[AQS即的简称，翻译过来就是抽象队列同步器的意思，由Doug Lea大神开发的。说他抽象是因为它提供的是一个基于队列的同步器框架，定义了一些基础功能方法（控制状态变量，获取和释放同步状态方法以及入队出队操作等），具体场景使用只需要根据需要实现对应的方法即可。我们在锁（比如ReentrantLock）、并发工具类（比如CountDownLatch）都可以看到内部类继承了，也就是说AQS才是这些类的基石。说了这么多，感觉把抽象说的越抽象了，下面我们从几个栗子入手吧。]]></description><category></category></item><item><title><![CDATA[并发：如何设计线程安全的类]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/151622001</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/151622001</guid><author>eclipseC</author><pubDate>Fri, 12 Sep 2025 16:40:32 +0800</pubDate><description><![CDATA[明确状态范围：识别所有构成对象状态的变量（包括引用对象的字段）。优先封装与封闭：通过实例封闭将状态限制在类内部，用内部锁协调访问。善用线程安全组件：尽量委托给线程安全的组件（如），减少手动同步。处理状态依赖：当组件状态存在依赖时，需额外加锁保证复合操作的原子性。安全发布对象：避免对象逸出，确保在完全初始化后再发布，使用finalvolatile或同步机制保证可见性。通过这些原则，可将复杂对象的线程安全问题分解为更小的、可管理的部分，从而降低并发编程的难度，提高代码的可靠性。]]></description><category></category></item><item><title><![CDATA[并发：使用volatile和不可变性实现线程安全]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/151612998</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/151612998</guid><author>eclipseC</author><pubDate>Fri, 12 Sep 2025 10:57:41 +0800</pubDate><description><![CDATA[Java并发编程实战》中的展示了volatile来实现线程安全。解决了简单缓存实现中可能出现的线程安全问题，同时避免了全量同步带来的性能开销。]]></description><category></category></item><item><title><![CDATA[Leetcode77:组合问题]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/151254242</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/151254242</guid><author>eclipseC</author><pubDate>Sat, 06 Sep 2025 13:29:00 +0800</pubDate><description><![CDATA[LeetCode 77题（组合）要求从1到n中选择k个数字的所有可能组合，且组合中的元素不能重复，顺序不影响组合的唯一性（例如[1,2]和[2,1]视为同一个组合）。这是一个典型的组合问题，适合用回溯算法解决。]]></description><category></category></item><item><title><![CDATA[LeetCode15:三数之和]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/151252190</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/151252190</guid><author>eclipseC</author><pubDate>Sat, 06 Sep 2025 11:46:52 +0800</pubDate><description><![CDATA[算法的时间复杂度为O(n²)，其中排序占O(n log n)，主体双指针遍历占O(n²)；空间复杂度为O(1)（不包括存储结果的空间）。]]></description><category></category></item><item><title><![CDATA[并发：对象的发布和逸出]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150864345</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150864345</guid><author>eclipseC</author><pubDate>Tue, 26 Aug 2025 17:14:01 +0800</pubDate><description><![CDATA[和是涉及对象可见性和线程安全的重要概念。理解这两个概念有助于避免因对象状态被意外访问或修改而导致的并发问题。]]></description><category></category></item><item><title><![CDATA[机器学习：贝叶斯派和频率派]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150796750</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150796750</guid><author>eclipseC</author><pubDate>Mon, 25 Aug 2025 23:28:38 +0800</pubDate><description><![CDATA[频率派和贝叶斯派分别给出了一系列的机器学习算法。频率派的观点导出了一系列的统计机器学习算法而贝叶斯派导出了概率图理论。在应用频率派的 MLE 方法时最优化理论占有重要地位。而贝叶斯派的算法无论是后验概率的建模还是应用这个后验进行推断时积分占有重要地位。因此采样积分方法如 MCMC 有很多应用。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：用接口模拟可扩展的枚举]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150772661</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150772661</guid><author>eclipseC</author><pubDate>Mon, 25 Aug 2025 16:19:02 +0800</pubDate><description><![CDATA[Java 的枚举类型本质上是final的，无法通过继承直接扩展。例如，若有一个表示基本算术操作的枚举（包含ADDSUBTRACT），后续若需添加新操作（如MULTIPLYDIVIDE），无法直接扩展原有枚举。：如何在不修改原有代码的情况下，扩展枚举的功能？通过定义一个公共接口，让多个枚举类实现该接口，客户端代码通过接口类型操作枚举实例，实现多态。Operation接口声明所有枚举需要实现的核心方法。基础枚举实现接口，提供默认操作（如加、减）。新枚举同样实现Operation接口，添加新操作（如乘、除）。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：enum 代替 int 常量]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150764391</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150764391</guid><author>eclipseC</author><pubDate>Mon, 25 Aug 2025 11:37:52 +0800</pubDate><description><![CDATA[ALIPAY(amount -> System.out.println("使用支付宝支付: ¥" + amount)),WECHAT(amount -> System.out.println("使用微信支付: ¥" + amount)),UNIONPAY(amount -> System.out.println("使用银联支付: ¥" + amount));// 测试结果：使用支付宝支付: ¥199.9使用微信支付: ¥88.8。]]></description><category></category></item><item><title><![CDATA[Leetcode3：无重复字符的最长子串（动态规划解法）]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150699466</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150699466</guid><author>eclipseC</author><pubDate>Sun, 24 Aug 2025 12:35:49 +0800</pubDate><description><![CDATA[设。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：优先考虑类型安全的异构容器]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150606153</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150606153</guid><author>eclipseC</author><pubDate>Fri, 22 Aug 2025 11:24:41 +0800</pubDate><description><![CDATA[指能够存储不同类型对象的容器（与普通泛型容器如List<T>只能存储单一类型T不同）。而则是在编译时就能保证存储和获取对象的类型一致性，避免运行时的实现。这类容器在依赖注入、序列化框架、配置管理等场景中广泛应用，其核心价值是在灵活存储多类型对象的同时，通过编译期检查规避类型错误。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：显式创建泛型数组是非法的,用泛型可 变参数声明方法却是合法的]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150576880</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150576880</guid><author>eclipseC</author><pubDate>Thu, 21 Aug 2025 10:31:02 +0800</pubDate><description><![CDATA[场景本质问题为何合法/非法？显式创建泛型数组无法在运行时保证数组元素的类型安全非法：直接违反数组的运行时类型检查特性，风险不可控。泛型可变参数方法底层依赖泛型数组，但使用场景更受限合法：为了易用性妥协，通过编译器警告和转移安全责任给开发者。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：请不要使用原生态类型]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150487547</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150487547</guid><author>eclipseC</author><pubDate>Mon, 18 Aug 2025 11:30:50 +0800</pubDate><description><![CDATA[在《Effective Java》的中，Joshua Bloch 强调了「」这一规则，并通过丰富的实例和详细分析，展示了泛型如何改善代码的表达力、类型安全性和灵活性。泛型是 Java 的一大飞跃，使得开发者能够编写更加通用和安全的代码。在 Java 中，原始类型（Raw Types） 是泛型引入之前所使用的一种写法，它不对类型进行参数化处理。例如，List是原始类型，而是泛型的用法。为了规避这些问题，应该尽量使用泛型代替原始类型。Stack<E>。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：限制源文件为单个顶级类]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150485061</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150485061</guid><author>eclipseC</author><pubDate>Mon, 18 Aug 2025 10:19:05 +0800</pubDate><description><![CDATA[而开发者在写代码时，可能会误以为这些包级私有类是封装的，从而在同一包的其他类中错误地使用了它们。当文件中包含多个类时，开发者必须深入阅读代码才能弄清楚文件中到底有哪些类以及它们的用途。如果某些类确实与顶级类紧密关联，只在其中范围使用，使用嵌套类代替顶级类。在源文件中定义多个顶级类可能导致文件管理的混乱，特别是在跨包引用的情况下。将每个顶级类放在单独的文件中，能让团队更好地管理和协作，减少冲突，同时提升代码审查的效率。的顶级类，那么源文件的名称必须与该类的名称完全相同（包括大小写）。且不嵌套在其他类中的类。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：静态成员类优于非静态成员类]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150427778</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150427778</guid><author>eclipseC</author><pubDate>Fri, 15 Aug 2025 17:28:40 +0800</pubDate><description><![CDATA[这一点在大规模系统中尤为重要，尤其是当类的引用关系复杂时，非静态成员类容易在不经意间导致外部类实例无法被垃圾回收。如果成员类并不需要访问外部类的非静态成员（属性或方法），将其设计为非静态类，会引入不必要的耦合。尽管静态成员类通常是更优的设计选择，但有时我们仍然会使用非静态成员类。静态成员类的实例化速度更快，因为它不需要与外部类实例挂钩，且不需要额外存储外部类实例的引用。当内部类必须访问外部类的某些状态（实例变量或非静态方法）时，非静态成员类是合理的选择。静态成员类的使用方式更简单，不需要关联外部类实例。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：类层次优于标签类]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150427181</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150427181</guid><author>eclipseC</author><pubDate>Fri, 15 Aug 2025 17:04:56 +0800</pubDate><description><![CDATA[标签类（Tagged Class）是一种反面设计模式，通常通过一个单一的类表示多种逻辑和行为，并使用“标签字段”来区分每种逻辑。// 标签字段，标识形状的类型// 用于矩形的属性// 用于圆形的属性// 构造圆// 构造矩形// 计算面积（根据标签字段的类型分支处理）default:在这个例子中，Figure使用一个Shape标签字段来标记它是一个矩形还是一个圆形，然后在构造器和方法中使用switch或if-else的判断逻辑来操作不同的字段。标签类设计的缺陷。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：为后代设计接口]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150426452</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150426452</guid><author>eclipseC</author><pubDate>Fri, 15 Aug 2025 16:39:48 +0800</pubDate><description><![CDATA[方法的新增行为在实现类中是"隐形的"，它可能会在实现类中引入行为变化，而开发或维护人员不一定意识到这些变化。例如，新增的方法可能需要特定的上下文或数据，而某些实现类可能没有这些条件。如果需要在现有接口上扩展新功能，而这个功能对现有实现类的意义不强，可以选择创建一个新接口，并用它补充现有接口。如果需要为接口提供某些通用功能，可以设计一个抽象类来实现接口，同时为需要默认行为的子类提供基本实现。接口应该是一个明确的"契约"，只是声明 “对象必须支持的方法”，具体如何实现则由实现类负责。的使用提出了重要的建议。]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：接口优于抽象类]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150425069</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150425069</guid><author>eclipseC</author><pubDate>Fri, 15 Aug 2025 15:59:39 +0800</pubDate><description><![CDATA[在 《Effective Java 第三版》中，作者 Joshua Bloch 对“接口优于抽象类”这一原则有着深入的探讨。在理解“接口优于抽象类”之前，我们需要明确二者的本质区别：书中的核心观点是：接口提供了更大的灵活性、更广泛的适用性以及更好的未来兼容性。因此，Joshua Bloch 在条目20中推荐开发者优先选择接口，原因如下：示例：接口的多重继承
相比抽象类，接口让一个类可以轻松拥有“多个行为”（复合式能力），而不需要受到单继承的限制。
书中例子常见的场景：  和  模式相比抽象类，接口更加关注对]]></description><category></category></item><item><title><![CDATA[Effective Java笔记：要么设计继承并提供文档说明,要么禁止继承]]></title><link>https://blog.youkuaiyun.com/eclipseC/article/details/150421244</link><guid>https://blog.youkuaiyun.com/eclipseC/article/details/150421244</guid><author>eclipseC</author><pubDate>Fri, 15 Aug 2025 13:51:48 +0800</pubDate><description><![CDATA[这个观点强调的是在使用继承时，设计者必须明确其意图，并为继承行为提供清晰的文档说明来指导子类的扩展。如果无法提供合适的设计和说明，那么禁止继承反而是更好的选择。在很多情况下，复合是一种可以代替继承的更安全的设计模式（见之前“复合优于继承”的讨论）。通过组合其他类而非继承，可以提高类的可维护性和封装性。当一个类的实现很容易因子类滥用而出问题时，应尽可能明确哪些部分是封闭的（不可重写），哪些部分开放给子类（可重写）。对于工具类（跟逻辑无关，只保存一些静态方法），禁止继承是一种推荐的设计方法。]]></description><category></category></item></channel></rss>