[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"articles-3-10":3},{"code":4,"msg":5,"data":6},200,"成功",{"list":7,"total":101},[8,21,30,39,48,57,66,75,84,93],{"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},"2005272316555096065","什么是 Spring Actuator？它有什么优势？","spring-actuator-youshi","Spring Boot Actuator 是 Spring Boot 提供的一个用于监控和管理应用程序的模块。它通过暴露一系列 HTTP 端点（endpoints）或 JMX 接口，让开发者和运维人员可以轻松地获取应用的运行时状态、健康状况、指标信息、配置详情等，而无需自己编写额外的监控代码。 一、Spring Actuator 的核心功能 健康检查（Health） 检查应用及其依赖（如数据库、Redis、外部服务）是否正常。 默认路径：\u002Factuator\u002Fhealth 应用信息（Info） 显示应用的基本信息，如版本、构建时间、Git 提交信息等。 默认路径：\u002Factuator\u002Finfo 指标监控（Metrics） 提供 JVM、内存、线程、HTTP 请求、GC 等系统和应用级指标。 默认路径：\u002Factuator\u002Fmetrics 环境变量（Environment） 查看所有配置属性（包括...",2073,6,"0","",2,0,55,"2025-12-28 21:39:10",{"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},"2004932213135699969","Spring Boot @Async 注解失效原因分析","spring-boot-async-zhujie","@Async 是 Spring 提供的一个核心注解，用于将方法调用变为异步执行。它依赖 Spring 的 AOP（面向切面编程）机制来实现。当你在一个方法上加上 @Async 时，Spring 会在运行时为该方法所在的 Bean 创建一个代理对象。所有对该方法的外部调用，实际上都是调用这个代理对象，由代理对象负责将方法的执行提交给一个线程池，从而实现异步效果。 基于这个原理，我们可以总结出 @Async 失效的几种典型场景。 调用者与被调用者在同一个类中（同类方法自调用） 这是 最常见 的失效场景。 原因： Spring 的 AOP 是基于代理实现的。只有通过 Spring 容器获取到的 Bean（即代理对象）去调用 @Async 方法时，AOP 切面才能生效。如果在同一个类的内部，一个方法直接调用另一个被 @Async 标注的方法，这个调用是对象内部的直接方法调用，没有经过 Spring...",5833,19,65,"2025-12-27 23:07:45",{"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":37,"likeCount":18,"commentCount":18,"publishTime":38},"2004486734715351042","为什么 Redis 设计为单线程？6.0 版本为何引入多线程？","redis-sheji-danxian-banben","Redis作为高性能缓存解决方案的行业标准，其线程模型的设计一直是开发者们关注的焦点。从纯粹的单线程到Redis 6.0引入多线程，这一演进过程体现了Redis开发者在保持简单性与提升性能之间的精巧平衡。本文将深入剖析Redis线程模型的演进历程、技术原理与实践应用，帮助读者全面理解这一关键设计。 一、Redis早期单线程模型（6.0之前） 1.1 单线程架构的设计理念 Redis最初采用单线程模型完全是一个经过深思熟虑的架构决策。这种设计基于以下几个关键考虑： 避免上下文切换开销：多线程调度需要在CPU之间频繁切换线程上下文，涉及寄存器替换、程序堆栈复位等开销，而单线程模型完全避免了这一开销。 避免同步机制开销：多线程必然需要引入锁等同步机制，而单线程模型天然无需考虑资源竞争问题。 简单可维护：Redis作者Salvatore Sanfilippo对代码简单性有着近乎偏执的追求，单线程模...",4691,15,56,"2025-12-26 17:37:32",{"id":40,"title":41,"slug":42,"summary":43,"wordCount":44,"readingTime":45,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":46,"likeCount":18,"commentCount":18,"publishTime":47},"2004173142191304705","Spring Cloud微服务中远程调用的超时时间应该设置为多少合适？","chaoshi-zhong-diaoyong-fuwu","引言：为什么需要关注超时设置？ 在微服务架构中，服务间的远程调用是系统的基础操作，然而网络的不确定性使得超时控制成为保障系统稳定性和韧性的关键。一个合理的超时策略不仅能防止资源阻塞，还能有效避免级联故障和雪崩效应的发生。本文将深入探讨Spring Cloud微服务架构中远程调用超时时间的合理设置方法。 一、超时设计的核心原则 1.1 根据业务特性分层设置 不同业务场景对超时的要求各不相同： 核心链路（如支付、订单提交）：超时时间应严格控制在1-3秒，避免长时间阻塞影响主流程 。 非核心链路（如评论、日志上报）：可适当放宽至5-10秒，允许一定延迟 。 同步调用：超时时间需覆盖正常响应时间加上网络波动冗余，通常2-5秒。 异步调用：通过消息队列解耦，不设硬性超时，依赖消息重试机制。 1.2 遵循\"80\u002F20原则\" 基于历史监控数据设置超时阈值： 统计接口的P95\u002FP99响应时间（95%\u002F99...",6108,20,52,"2025-12-25 20:51:31",{"id":49,"title":50,"slug":51,"summary":52,"wordCount":53,"readingTime":54,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":55,"likeCount":18,"commentCount":18,"publishTime":56},"2004169834944851970","MySQL索引优化实战：深入理解最左前缀匹配原则","mysql-shenru-lijie-zuo","在数据库优化领域中，索引是提升查询性能的关键工具，而最左前缀匹配原则则是高效使用联合索引的核心原则。本文将深入解析这一原则的原理、应用场景及实战技巧。 1. 索引基础与最左前缀原则概述 1.1 什么是联合索引 联合索引（复合索引）是指包含多个列的索引。例如，我们可以为users表的first_name和last_name列创建联合索引： 与单列索引不同，联合索引按照定义时的列顺序构建B+树结构。 1.2 最左前缀原则的核心概念 最左前缀原则指的是：MySQL在使用联合索引时，只能从索引的最左列开始匹配，且必须是连续的列序列。这意味着查询条件必须包含联合索引的最左列，才能有效利用该索引。 举例来说，对于索引(a, b, c)： ✅ 有效的查询：WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b = 2 AND c = 3 ❌...",3849,12,48,"2025-12-25 20:38:21",{"id":58,"title":59,"slug":60,"summary":61,"wordCount":62,"readingTime":63,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":64,"likeCount":18,"commentCount":18,"publishTime":65},"2003467831767789569","JavaScript数字精度丢失问题：原因、案例与解决方案","javascript-diushi-wenti-yuanyin","引言 在日常JavaScript开发中，许多开发者都遇到过这样一个奇怪的现象：0.1 + 0.2 !== 0.3。这种精度丢失问题不仅会影响计算结果的准确性，在金融、科学计算等场景下甚至可能导致严重的业务问题。本文将深入探讨JavaScript数字精度丢失的原因，并通过实际案例展示多种解决方案。 精度丢失的根本原因 JavaScript中的数字类型采用IEEE 754双精度浮点数格式表示，这是一种64位的二进制表示法，其中1位用于符号位，11位用于指数位，52位用于尾数位。 这种表示法的局限性在于，某些十进制小数无法精确转换为二进制小数。例如，0.1在二进制中是一个无限循环小数：0.0001100110011...，而0.2则是0.001100110011...。由于计算机存储位数有限，这些无限循环小数会被截断，从而导致精度丢失。 不仅小数存在精度问题，大整数同样面临精度挑战。JavaSc...",2382,7,66,"2025-12-23 22:08:49",{"id":67,"title":68,"slug":69,"summary":70,"wordCount":71,"readingTime":72,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":73,"likeCount":18,"commentCount":18,"publishTime":74},"2003465410966515714","为什么IDEA不建议使用append拼接字符串？","shiyong-pinjie-append-jianyi","IDEA 之所以不建议在某些情况下手动使用 StringBuilder.append() 进行字符串拼接，并提示可以将其直接替换为 String（即使用 + 运算符），根本原因在于项目使用的 JDK 版本（>= 9）。从 Java 9 开始，JVM 在字符串拼接方面做了重大优化，使得简单的 + 运算符在性能和简洁性上超越了或等同于手动编写的 StringBuilder 代码。 这与我们熟知的“在循环或复杂拼接中必须使用 StringBuilder”的八股文形成了看似矛盾的冲突，但实际上反映了最佳实践是随着技术发展而演进的。 详细解析：从 Java 8 到 Java 9 的演变 为了理解IDEA的提示，我们需要回顾并对比两个时代的不同机制。 1.",949,3,57,"2025-12-23 21:59:11",{"id":76,"title":77,"slug":78,"summary":79,"wordCount":80,"readingTime":81,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":82,"likeCount":18,"commentCount":18,"publishTime":83},"2003005387844939778","Java字符串三剑客：特性、场景与避坑指南","java-texing-changjing-sanjianke","在Java开发中，String、StringBuffer和StringBuilder是处理文本的核心类。选择不当会引发性能问题和线程安全隐患。下面通过对比介绍和代码示例，帮助你精准选用。 1 核心特性对比 下面的表格直观对比了这三个类的核心差异，方便您快速把握重点。 特性 String StringBuilder StringBuffer 可变性 ❌ 不可变 ✅ 可变 ✅ 可变 线程安全 ✅ 安全（因不可变） ❌ 不安全 ✅ 安全（synchronized实现） 性能 低（频繁修改时） 高（单线程最佳） 中（有同步开销） 适用场景 常量、少量操作 单线程下大量修改 多线程下大量修改 简单来说： String 是字符串常量，适用于表示那些一旦创建就不再改变的值。 StringBuilder 和 StringBuffer 是字符串变量，适用于需要频繁修改字符串内容的场景。两者的核心区别在于线程...",4337,14,49,"2025-12-22 15:31:14",{"id":85,"title":86,"slug":87,"summary":88,"wordCount":89,"readingTime":90,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":91,"likeCount":18,"commentCount":18,"publishTime":92},"2003004849359220738","MySQL随机查询性能优化：扔掉ORDER BY RAND()的最佳实践","mysql-order-rand-youhua","面对海量数据随机推荐需求，如何平衡性能与随机性成为关键挑战 背景与需求分析 在电商平台开发中，我们经常需要实现\"随机推荐\"功能：从商品库中随机选取指定数量的商品展示给用户。假设商品表(product)有10000条数据，需要随机获取3个不重复的商品。 许多开发者第一反应是使用ORDER BY RAND()实现，但这种方法的性能代价极高，在处理大量数据时几乎不可用。 为什么不推荐使用ORDER BY RAND()？ 这条SQL语句的问题在于： 需要全表扫描：MySQL必须读取所有行并为每行分配随机值 使用临时表：需要创建临时表存储所有数据 文件排序：需要对整个临时表进行排序 性能随数据量增长急剧下降：万级数据尚可勉强接受，十万级以上几乎不可用 执行计划中会出现\"Using temporary\"和\"Using filesort\"，这些都是性能杀手。 高性能替代方案实现与测试 方案一：应用层随机...",5471,18,58,"2025-12-22 15:29:05",{"id":94,"title":95,"slug":96,"summary":97,"wordCount":98,"readingTime":99,"categoryId":15,"tags":16,"coverImage":16,"thumbnail":16,"status":17,"isTop":18,"isRecommended":18,"allowComments":18,"password":16,"viewCount":46,"likeCount":18,"commentCount":18,"publishTime":100},"2003004149879336961","为什么生产环境必须显式设置 -Xms 和 -Xmx：从默认规则到最佳实践","xms-xmx-shi-shezhi","默认规则太保守，生产环境不可预测，手动配置是稳定性的基石。 在现代Java应用部署中，显式设置JVM堆内存参数（-Xms和-Xmx） 不再是可选优化，而是保证应用稳定性的必要条件。本文将深入分析默认规则的缺陷，解释显式设置的好处，并提供可直接套用的生产环境配置方案。 1 默认内存规则的陷阱与风险 JVM设计了堆内存的默认分配规则，但这些规则在生产环境中往往成为性能瓶颈和稳定性隐患。 1.1 默认规则剖析 根据JVM的默认行为，堆内存大小按以下规则计算： 初始堆大小（-Xms） = 物理内存大小 \u002F 64 最大堆大小（-Xmx） = 物理内存大小 \u002F 4 这一规则在实际环境中产生显著问题: 机器内存 默认 -Xms 默认 -Xmx 问题分析 8 GB 128 MB 2 GB 起步太小导致频繁GC，上限不足易OOM 16 GB 256 MB 4 GB 内存浪费严重，性能抖动明显 32 GB 5...",2550,8,"2025-12-22 15:26:18","43"]