[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"articles-3-10":3},{"code":4,"msg":5,"data":6},200,"成功",{"list":7,"total":95},[8,21,30,38,46,54,63,70,78,86],{"id":9,"title":10,"slug":11,"summary":12,"wordCount":13,"readingTime":14,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":19,"likeCount":18,"commentCount":18,"publishTime":20},"2004932213135699969","Spring Boot @Async 注解失效原因分析","spring-boot-async-zhujieshixiaoyuanyinfenxi","@Async 是 Spring 提供的一个核心注解，用于将方法调用变为异步执行。它依赖 Spring 的 AOP（面向切面编程）机制来实现。当你在一个方法上加上 @Async 时，Spring 会在运行时为该方法所在的 Bean 创建一个代理对象。所有对该方法的外部调用，实际上都是调用这个代理对象，由代理对象负责将方法的执行提交给一个线程池，从而实现异步效果。 基于这个原理，我们可以总结出 @Async 失效的几种典型场景。 --- 1. 调用者与被调用者在同一个类中（同类方法自调用） 这是 最常见 的失效场景。 原因： Spring 的 AOP 是基于代理实现的。只有通过 Spring 容器获取到的 Bean（即代理对象）去调用 @Async 方法时，AOP 切面才能生效。如果在同一个类的内部，一个方法直接调用另一个被 @Async 标注的方法，这个调用是对象内部的直接方法调用，没有经过...",5833,19,"0","",2,0,18,"2025-12-27 23:07:45",{"id":22,"title":23,"slug":24,"summary":25,"wordCount":26,"readingTime":27,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":28,"likeCount":18,"commentCount":18,"publishTime":29},"2004486734715351042","为什么 Redis 设计为单线程？6.0 版本为何引入多线程？","weishenme-redis-shejiweidanxiancheng60-banbenweiheyinruduoxiancheng","Redis作为高性能缓存解决方案的行业标准，其线程模型的设计一直是开发者们关注的焦点。从纯粹的单线程到Redis 6.0引入多线程，这一演进过程体现了Redis开发者在保持简单性与提升性能之间的精巧平衡。本文将深入剖析Redis线程模型的演进历程、技术原理与实践应用，帮助读者全面理解这一关键设计。 ## 一、Redis早期单线程模型（6.0之前） ### 1.1 单线程架构的设计理念 Redis最初采用单线程模型完全是一个经过深思熟虑的架构决策。这种设计基于以下几个关键考虑： - **避免上下文切换开销**：多线程调度需要在CPU之间频繁切换线程上下文，涉及寄存器替换、程序堆栈复位等开销，而单线程模型完全避免了这一开销。 - **避免同步机制开销**：多线程必然需要引入锁等同步机制，而单线程模型天然无需考虑资源竞争问题。 - **简单可维护**：Redis作者Salvatore Sanfi...",4691,15,12,"2025-12-26 17:37:32",{"id":31,"title":32,"slug":33,"summary":34,"wordCount":35,"readingTime":36,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":28,"likeCount":18,"commentCount":18,"publishTime":37},"2004173142191304705","Spring Cloud微服务中远程调用的超时时间应该设置为多少合适？","spring-cloudweifuwuzhongyuanchengdiaoyongdechaoshishijianyinggaishezhiweiduoshaoheshi","## 引言：为什么需要关注超时设置？ 在微服务架构中，服务间的远程调用是系统的基础操作，然而网络的不确定性使得超时控制成为保障系统**稳定性和韧性**的关键。一个合理的超时策略不仅能防止资源阻塞，还能有效避免**级联故障**和**雪崩效应**的发生。本文将深入探讨Spring Cloud微服务架构中远程调用超时时间的合理设置方法。 ## 一、超时设计的核心原则 ### 1.1 根据业务特性分层设置 不同业务场景对超时的要求各不相同： - **核心链路**（如支付、订单提交）：超时时间应严格控制在**1-3秒**，避免长时间阻塞影响主流程 。 - **非核心链路**（如评论、日志上报）：可适当放宽至**5-10秒**，允许一定延迟 。 - **同步调用**：超时时间需覆盖正常响应时间加上网络波动冗余，通常**2-5秒**。 - **异步调用**：通过消息队列解耦，不设硬性超时，依赖消息重试机...",6108,20,"2025-12-25 20:51:31",{"id":39,"title":40,"slug":41,"summary":42,"wordCount":43,"readingTime":28,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":44,"likeCount":18,"commentCount":18,"publishTime":45},"2004169834944851970","MySQL索引优化实战：深入理解最左前缀匹配原则","mysqlsuoyinyouhuashizhanshenrulijiezuizuoqianzhuipipeiyuanze","在数据库优化领域中，索引是提升查询性能的关键工具，而**最左前缀匹配原则**则是高效使用联合索引的核心原则。本文将深入解析这一原则的原理、应用场景及实战技巧。 ## 1. 索引基础与最左前缀原则概述 ### 1.1 什么是联合索引 联合索引（复合索引）是指包含多个列的索引。例如，我们可以为`users`表的`first_name`和`last_name`列创建联合索引： ```sql CREATE INDEX idx_name ON users(first_name, last_name); ``` 与单列索引不同，联合索引按照定义时的列顺序构建B+树结构。 ### 1.2 最左前缀原则的核心概念 最左前缀原则指的是：**MySQL在使用联合索引时，只能从索引的最左列开始匹配，且必须是连续的列序列**。这意味着查询条件必须包含联合索引的最左列，才能有效利用该索引。...",3849,11,"2025-12-25 20:38:21",{"id":47,"title":48,"slug":49,"summary":50,"wordCount":51,"readingTime":52,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":19,"likeCount":18,"commentCount":18,"publishTime":53},"2003467831767789569","JavaScript数字精度丢失问题：原因、案例与解决方案","javascriptshuzijingdudiushiwentiyuanyinanliyujiejuefangan","## 引言 在日常JavaScript开发中，许多开发者都遇到过这样一个奇怪的现象：`0.1 + 0.2 !== 0.3`。这种精度丢失问题不仅会影响计算结果的准确性，在金融、科学计算等场景下甚至可能导致严重的业务问题。本文将深入探讨JavaScript数字精度丢失的原因，并通过实际案例展示多种解决方案。 ## 精度丢失的根本原因 JavaScript中的数字类型采用**IEEE 754双精度浮点数格式**表示，这是一种64位的二进制表示法，其中1位用于符号位，11位用于指数位，52位用于尾数位。 这种表示法的局限性在于，**某些十进制小数无法精确转换为二进制小数**。例如，0.1在二进制中是一个无限循环小数：`0.0001100110011...`，而0.2则是`0.001100110011...`。由于计算机存储位数有限，这些无限循环小数会被截断，从而导致精度丢失。 不仅小数存在精度问...",2382,7,"2025-12-23 22:08:49",{"id":55,"title":56,"slug":57,"summary":58,"wordCount":59,"readingTime":60,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":61,"likeCount":18,"commentCount":18,"publishTime":62},"2003465410966515714","为什么IDEA不建议使用append拼接字符串？","weishenmeideabujianyishiyongappendpinjiezifuchuan","IDEA 之所以不建议在某些情况下手动使用 `StringBuilder.append()` 进行字符串拼接，并提示可以将其直接替换为 `String`（即使用 `+` 运算符），**根本原因在于项目使用的 JDK 版本（>= 9）。从 Java 9 开始，JVM 在字符串拼接方面做了重大优化，使得简单的 `+` 运算符在性能和简洁性上超越了或等同于手动编写的 `StringBuilder` 代码。** 这与我们熟知的“在循环或复杂拼接中必须使用 `StringBuilder`”的八股文形成了看似矛盾的冲突，但实际上反映了最佳实践是随着技术发展而演进的。 --- ### 详细解析：从 Java 8 到 Java 9 的演变 为了理解IDEA的提示，我们需要回顾并对比两个时代的不同机制。 #### 1.",949,3,14,"2025-12-23 21:59:11",{"id":64,"title":65,"slug":66,"summary":67,"wordCount":68,"readingTime":61,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":61,"likeCount":18,"commentCount":18,"publishTime":69},"2003005387844939778","Java字符串三剑客：特性、场景与避坑指南","javazifuchuansanjianketexingchangjingyubikengzhinan","> 在Java开发中，String、StringBuffer和StringBuilder是处理文本的核心类。选择不当会引发性能问题和线程安全隐患。下面通过对比介绍和代码示例，帮助你精准选用。 ## 1 核心特性对比 下面的表格直观对比了这三个类的核心差异，方便您快速把握重点。 | 特性 | String | StringBuilder | StringBuffer | | :--- | :--- | :--- | :--- | | **可变性** | ❌ 不可变 | ✅ 可变 | ✅ 可变 | | **线程安全** | ✅ 安全（因不可变） | ❌ 不安全 | ✅ 安全（synchronized实现） | | **性能** | 低（频繁修改时） | 高（单线程最佳） | 中（有同步开销） | | **适用场景** | 常量、少量操作 | 单线程下大量修改 | 多线程下大量修改 | **简单...",4337,"2025-12-22 15:31:14",{"id":71,"title":72,"slug":73,"summary":74,"wordCount":75,"readingTime":19,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":76,"likeCount":18,"commentCount":18,"publishTime":77},"2003004849359220738","MySQL随机查询性能优化：扔掉ORDER BY RAND()的最佳实践","mysqlsuijichaxunxingnengyouhuarengdiaoorder-by-randdezuijiashijian","> 面对海量数据随机推荐需求，如何平衡性能与随机性成为关键挑战 ## 背景与需求分析 在电商平台开发中，我们经常需要实现\"随机推荐\"功能：从商品库中随机选取指定数量的商品展示给用户。假设商品表(product)有10000条数据，需要随机获取3个不重复的商品。 许多开发者第一反应是使用`ORDER BY RAND()`实现，但这种方法的性能代价极高，在处理大量数据时几乎不可用。 ## 为什么不推荐使用ORDER BY RAND()？ ```sql -- 常见但不推荐的方案 SELECT * FROM product ORDER BY RAND() LIMIT 3; ``` 这条SQL语句的问题在于： - **需要全表扫描**：MySQL必须读取所有行并为每行分配随机值 - **使用临时表**：需要创建临时表存储所有数据 - **文件排序**：需要对整个临时表进行排序 - **性能随数据量增...",5471,13,"2025-12-22 15:29:05",{"id":79,"title":80,"slug":81,"summary":82,"wordCount":83,"readingTime":84,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":27,"likeCount":18,"commentCount":18,"publishTime":85},"2003004149879336961","为什么生产环境必须显式设置 -Xms 和 -Xmx：从默认规则到最佳实践","weishenmeshengchanhuanjingbixuxianshishezhi-xms-he-xmxcongmorenguizedaozuijiashijian","> 默认规则太保守，生产环境不可预测，手动配置是稳定性的基石。 在现代Java应用部署中，**显式设置JVM堆内存参数（-Xms和-Xmx）** 不再是可选优化，而是保证应用稳定性的必要条件。本文将深入分析默认规则的缺陷，解释显式设置的好处，并提供可直接套用的生产环境配置方案。 ## 1 默认内存规则的陷阱与风险 JVM设计了堆内存的默认分配规则，但这些规则在生产环境中往往成为**性能瓶颈和稳定性隐患**。 ### 1.1 默认规则剖析 根据JVM的默认行为，堆内存大小按以下规则计算： - **初始堆大小（-Xms）** = 物理内存大小 \u002F 64 - **最大堆大小（-Xmx）** = 物理内存大小 \u002F 4 这一规则在实际环境中产生显著问题: | 机器内存 | 默认 -Xms | 默认 -Xmx | 问题分析 | |---------|-----------|-----------|--...",2550,8,"2025-12-22 15:26:18",{"id":87,"title":88,"slug":89,"summary":90,"wordCount":91,"readingTime":92,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":93,"likeCount":18,"commentCount":18,"publishTime":94},"2002993510968520705","Apache Commons CollectionUtils 工具类详解：方法介绍与实战应用","apache-commons-collectionutils-gongjuleixiangjiefangfajieshaoyushizhanyingyong","## 1. 概述 `org.apache.commons.collections4.CollectionUtils` 是 Apache Commons Collections 库中的一个**核心工具类**，专门用于简化 Java 集合（List、Set、Map 等）的常见操作。它提供了丰富的静态方法，涵盖了集合的**空值判断**、**集合运算**、**过滤转换**、**比较统计**等多种场景，能够显著减少冗余代码，提高开发效率和代码可读性。 在传统的 Java 开发中，我们经常需要编写重复的代码来处理集合，例如手动判断集合是否为空、使用循环实现集合的交集和并集操作等。这些代码不仅冗长，而且容易出错。CollectionUtils 工具类的出现，使得我们能够通过**一行代码**完成复杂的集合操作，让开发人员更专注于业务逻辑而非底层实现。 **工具类优势总结：** -...",17481,58,16,"2025-12-22 14:44:01","42"]