Honesty的个人记录博客，记录生活中的趣事 分享一些个人技术观点, HeHouHui,HeHui,明厚,HeHouHui博客,HeHouHui网站,HeHouHui Java

2025 火山引擎 FORCE 冬会核心技术聚焦 “从算力竞赛到效率革命” 的范式转移，通过豆包 1.8 大模型、Seed-Thinking-v1.5 推理引擎与 UltraMem 超稀疏架构的全栈协同，破解了 AI 原生时代 “性能、成本、时延” 不可能三角。核心技术涵盖：豆包 1.8 的动态计算分配（SID）与多模态时空注意力重构，实现任务适配的资源高效调度；Seed-Thinking-v1.5 的过程奖励模型（PRM）与 BeyondAIME 反污染数据集，提升复杂推理精度；UltraMem 的 TDQKR 张量分解与 IVE 隐式参数扩展，突破大模型显存与部署瓶颈。相关成果发表于 ICLR 2025 等顶会，支持国产算力昇腾适配与企业私有化知识注入，实测实现 AI 推理成本每 12 个月下降 90%。典型落地案例包括奔驰智能座舱离线交互优化，为金融、零售等行业提供低成本、高性能的 AI 原生解决方案。

 2025火山引擎FORCE大会·冬 三大核心技术：AI原生时代的底层逻辑与实践路径

在响应式编程愈发流行的今天，缓存作为提升系统性能的核心组件，其设计是否适配响应式架构直接决定了系统的吞吐量和响应性。传统的同步缓存（如Guava LoadingCache）在WebFlux等响应式框架中易引发线程阻塞、背压失控等问题，而Caffeine作为新一代高性能缓存框架，其AsyncCache组件专为异步/响应式场景设计，成为响应式架构下缓存层的首选。
本文将从Caffeine AsyncCache的核心配置入手，结合实际业务场景，深度讲解其与WebFlux、R2DBC、ReactiveRedis的整合实践，并梳理开发过程中必须规避的核心坑点；同时新增底层源码解析、架构设计原理、核心设计思想及算法公式等深度内容，补充复杂场景处理方案，通过时序图清晰呈现缓存流转逻辑，为响应式架构下的缓存设计提供完整解决方案。

Caffeine AsyncCache：响应式架构下（WebFlux, R2DBC, ReactiveRedis）的缓存实践

深度整合Spring WebFlux、R2DBC、Lettuce Reactive Redis与Java虚拟线程，构建端到端非阻塞高性能Web应用。揭示90%开发者会踩的线程调度混乱、阻塞调用、副作用游离等反范式陷阱，提供BlockHound检测工具与实战口诀。详解关键/非关键副作用、分布式事务等4大生产级最佳实践场景，融合虚拟线程简化遗留代码集成。遵循本文规范，可规避常见陷阱，打造高伸缩、低延迟的现代化响应式系统，驾驭海量并发洪流。

事件驱动：WebFlux、R2DBC，Lettuce Reactive Redis与虚拟线程下的高性能Web项目构建指南

这篇文章记录了我如何从一个简单的想法，通过100多次Git提交，逐步打造出现在的"关于我"页面。涵盖设计思路里的便当盒布局与玻璃态美学、技术实现中的3D技术球坑点、和API的拉锯战，以及最终因PWA影响核心功能而忍痛放弃的纠结过程。这是一场充满像素级纠结、bug大战与创作快感的真实开发故事。

"关于我"页面创作之旅

《Faiss vector database：高维向量检索的学术基石与向量数据库中的核心角色》基于 20 篇权威文献，深度解析 Faiss 、PQ/IVF/HNSW 核心算法、CPU/GPU 硬件加速及向量数据库中的索引内核角色，为高维检索研究与落地提供学术支撑（关键词：Faiss、高维向量检索、PQ/IVF/HNSW、向量数据库、学术解析）

高维向量检索 Faiss vector database：向量数据库的基石与核心角色 —— 解析 PQ/IVF/HNSW 算法原理、CPU/GPU 底层实现、量化误差模型及动态索引机制，详解其在 RAG / 推荐系统中的价值与工业应用

《Faiss vector database 深度学习指南》聚焦向量检索工具 Faiss，拆解其核心原理、IVF-PQ/HNSW 等索引算法，详解 CPU/GPU 硬件加速、索引持久化与动态数据处理，Faiss安装，提供 RAG / 推荐系统实战方案及性能调优技巧，助力高维向量检索落地（关键词：Faiss、向量检索、GPU 加速、RAG、工业级调优）

Faiss vector database 深度学习指南：从背景到架构&算法&安装  —— 向量检索核心算法（IVF-PQ/HNSW）解析、CPU/GPU 加速优化、索引构建与持久化、动态数据处理方案

下班后，雨停的上海街头映着霓虹，我穿过南京西路的人潮，拐进愚园路，在全家买一瓶乌龙茶，回到家。厨房灯亮起，炖番茄牛腩、泡妈妈晒的干菊花，和猫一起把日子煮成一碗热汤。电脑打开又合上，唯一的胜利是把碗洗干净

今天不想做英雄，只想把碗洗干净。

本文全面解析大型语言模型（LLM）上下文工程的核心体系，指出 LLM 性能关键已从 “参数竞赛” 转向 “上下文质量”。文中先明确上下文工程的定义与数学形式化表达，对比其与传统提示工程的本质差异；再拆解三大基础组件（检索生成、上下文处理、记忆管理）的技术细节；随后详解四大系统架构（RAG、内存管理、工具集成推理、多智能体协作）的落地逻辑；最后分析核心不对称性、评估困境等技术挑战，并展望未来突破方向，为 AI开发学习者提供从理论到实践的完整指南。

LLM Context Engineering 大模型上下文工程：系统性学习核心原理与实现架构

本文通俗解读 LLM 上下文工程， LLM 性能不只靠参数，更依赖上下文。文中拆解核心概念（指令、外部知识、记忆等上下文 “零件” 及组装逻辑）、关键技术（用于查资料的 RAG、辅助推理的思维链、记忆管理），以及新手可搭建的可落地系统（简易 RAG、长会话记忆工具）。还分享常见问题及 3 个月学习路径，无需复杂代码，助力新手用 LangChain/FAISS 等工具让 LLM 更精准实用

小白入门LLM Context上下文工程：从基础到实践，通俗易懂讲明白

Context Engineering（上下文工程）、LLM（大语言模型）、RAG（检索增强生成）分层记忆（短期 / 中期 / 长期记忆）、上下文治理（压缩 / 路由 / 窗口预算 / 评分）
• LLM 多轮对话失忆解决方法（
• RAG 的七宗罪（检索噪声 / 窗口爆炸）优化方案
• Context Engineering （分层 / 压缩 / 路由）
• LLM 上下文窗口预算算法设计
• Context Engineering 与 RAG 协同
• 降低 LLM 使用成本（Context 压缩 / 缓存机制）
• Context Engineering 常见误区（记忆混淆 / 安全缺失）

从 RAG 到 Context Engineering：大语言模型时代的上下文治理革命

本文聚焦 RAG（检索增强生成）局限（窗口爆炸、多轮失忆、时效性差等），详解 Context Engineering（上下文工程）定义、核心模块（记忆管理、知识检索增强、动态适配、安全边界）及避坑技巧， LangChain、LlamaIndex 等工具与官方学习资源

从RAG到Context Engineering：重新定义AI系统的认知能力边界

增量静态再生（ISR）的学习了解，解析 ISR 如何解决传统渲染（CSR/SSR/SSG）的痛点 ISR 核心原理（revalidate 缓存有效期、fallback 策略）。主流技术栈对比（Next.js/Nuxt 3/SvelteKit + 国内云厂商方案）、优缺点分析及落地学习路径

什么是增量静态再生(ISR)技术？：从Next.js & Nuxt 开始入门

5年博客网站历程与技术选型的变更路线

从Java到Next.js：5年博客建站的“省心省钱”之路

本文深度解析编译技术（AOT/JIT/ 字节码 / 机器码），结合 Java（JVM/GraalVM）、Python（CPython/PyPy）、Go（静态编译 / 交叉编译）案例，解答启动慢、跨平台等疑问，含云原生适配、3 个实战实验，帮开发者理解底层逻辑，优化性能与技术选型。

了解编程语言的编译器：从 CPU 指令到云原生，一次搞懂编译、字节码、JIT/AOT 的底层逻辑

本文是 MySQL InnoDB 存储引擎全景式指南，结合 MySQL 8.0 官方文档，从底层架构切入，拆解内存（缓冲池、redo/undo 日志缓冲）与磁盘（表空间、段页模型）的协同逻辑；深入 B + 树索引设计（对比红黑树 / B 树的优劣）、事务 ACID 实现（undo log 保障原子性、redo log 确保持久化、MVCC 解决读写阻塞）；提供性能优化方案（索引避坑、参数调优、SQL 改写），并覆盖主从架构、分库分表等扩展手段。帮 DBA、后端开发者攻克高并发、大数据量场景下的 InnoDB 性能瓶颈，适配电商、金融等企业级业务需求，兼具原理深度与落地价值。

MySQL InnoDB存储引擎深度解析：架构、原理与实践

本文是 InnoDB 全链路技术指南，聚焦 “索引→事务→优化→分库分表” 核心链路，结合 MySQL 8.0 官方文档，拆解 B + 树索引选型逻辑（对比红黑树 / B 树）、聚簇 / 非聚簇索引差异，详解回表、覆盖索引、最左匹配原则；剖析事务 ACID 实现（undo/redo log、MVCC），对比 4 种隔离级别；提供慢查询优化（explain 分析、索引避坑）、读写瓶颈解决方案（主从分离、Redis 缓存、Elasticsearch），最终落地分库分表策略（哈希 / 范围拆分、分布式 ID、双写迁移），帮开发者解决高并发、大数据量场景下的 InnoDB 性能问题，速记关键知识点。

MySQL InnoDB核心原理与实践：从索引到分库分表的决策速记

本文系统梳理 MySQL 优化器调试核心工具（含EXPLAIN、EXPLAIN ANALYZE、optimizer trace等），通过 5 个实战案例演示工具组合排障技巧，详解优化器决策逻辑与调优方法。同时整理 20 + 高频面试题及原理级答案，助开发者从 “被动接受执行计划” 升级为 “主动调试优化器”，轻松应对实战排障与面试挑战。

MySQL优化器(5)调试工具与面试指南：从“猜优化器”到“懂优化器”

本文全面解析 MySQL 成本模型的底层逻辑，详解 IO、CPU、内存三大成本的计算原理与公式，结合统计信息（含直方图）、源码分析与实战调优案例，揭秘优化器如何通过成本估算决策执行计划，助开发者解决 “索引失效”“执行计划异常” 等问题，掌握成本模型调优技巧。

MySQL优化器(4)成本模型解剖：优化器的“成本”到底怎么计算的？

本文深度解析 MySQL 超图优化器的进化逻辑，从旧优化器左深树局限讲起，拆解超图丛生树连接、动态规划选优核心原理，结合源码与 10 表连接、分区表等实战案例，详解调优参数与避坑指南，助理解这一 "智能大脑" 如何让复杂查询性能提升数倍。

MySQL优化器(3)超图优化器解析：MySQL优化器的“智能大脑”进化

本文将 MySQL 官方文档作为优化器 “调优字典” 深读解析，详解优化器逻辑转换、分区裁剪、范围优化等核心规则，结合开发场景拆解成本估算与执行计划决策逻辑，助开发者通过文档掌握优化器原理，提升 SQL 调优效率。

MySQL优化器(2)官方文档深读笔记：优化器的“操作手册”全解析

MySQL 优化器是数据库性能核心，从规则驱动到动态决策历经多阶段进化。本文作为栏目序篇，解析其进化逻辑，助开发者掌握性能调优关键，揭开性能优化史序幕。

MySQL优化器(1)编年史：从 “规则执行者” 到 “成本决策者” 的演化之路 读懂进化，掌控性能

本文聚焦 Spring Boot 配置体系设计，解析 @Configuration、@Bean 等核心注解原理，详解 proxyBeanMethods 代理机制与 @Conditional 条件装配逻辑。结合 SPI 机制 2.7 版本前后演进差异，串联 BeanDefinition 生命周期与 Context 空间底层逻辑，阐释开闭原则在组件扩展中的落地，为配置设计提供从注解到 SPI 的完整指南。

从注解到SPI：Spring Boot配置体系的设计艺术

本文解析 Spring Boot 组件配置的优雅设计，围绕 @Configuration、@Bean 等核心注解，详解 proxyBeanMethods 代理机制、@Conditional 条件装配及 SPI 演进。结合 Bean 生命周期管理，阐释开闭原则、类可见性等设计思想的落地，为打造高可扩展组件配置提供从原理到实践的指南。

聊聊一个优雅组件配置设计该长啥样：从SpringBoot @Configuration到开闭原则，一次说透！

详解 Spring Boot Cache 核心技术，包括 @Cacheable 配置、CacheManager 使用、Redis 缓存选型与二级缓存实战，教你批量缓存优化技巧，轻松提升应用性能。Covering Spring Boot Cache essentials: @Cacheable setup, CacheManager, Redis selection, two-level & batch caching to boost app performance effectively.

Spring Boot Cache 解刨：@Cacheable 注解用法 + Redis 缓存优化，从架构设计到批量缓存性能提升指南

本文围绕 MySQL 行值表达式（Row Value Expression）展开，Mysql RVC,Mysql元组比较,Row Value Constructor/Comparison,涵盖概念解析、版本支持历程及语法用法，详解字典序比较规则与底层优化原理。通过性能实测对比传统写法与行值写法的差异，总结索引匹配、版本兼容等坑点，结合排行榜翻页、唯一性校验等实战场景，提炼出行值表达式在简化 SQL、提升查询效率（如 range 扫描优化）上的核心价值与最佳实践。

MySQL行值表达式：从“一脸懵”到“玩明白”的实战指南; Mysql RVC,Mysql元组比较,Row Value Constructor/Comparison

短短一篇全文总结：Spring Bean 生命周期, Spring Bean 作用域，IoC 容器，Bean 加载机制

🌱一篇总结速通 Spring Bean 生命周期：从“出生”到“入土”的 超爽攻略 📖

浮点数转换、JDK 浮点数版本差异、IEEE 754 标准、Ryu 算法、FastFloat 算法、性能优化、缓存机制、版本升级建议。

JDK 8至24浮点数转换底层原理与优化演进

涵盖 IEEE 754 浮点数标准、十进制二进制转换、单双精度格式、特殊值处理、字节序兼容、精度优化技巧、高性能转换库及硬件加速方案，助开发者解决浮点数转换性能与精度难题。

浮点数转换IEEE 754标准：从性能损耗原理到高并发场景的优化实践

Gemini CLI是谷歌开源的开发者AI智能体工具，支持免费调用Gemini 2.5 Pro模型。它拥有100万token超大上下文，可实现代码生成、项目分析、实时搜索等功能。本文详解安装步骤、核心命令与避坑指南，助你轻松解锁AI驱动的开发效率提升技巧，让终端中的AI能力成为开发好帮手。

Gemini CLI 详细指南：不止命令行，更是你的AI智能体搭子 🤖✨

Spring AI RAG 实战指南：基于 Spring Boot 构建智能问答系统，集成 OpenAI、PgVector 与 Elasticsearch，实现文档检索、对话记忆、查询优化与多级缓存，解决 AI 幻觉问题，适用于企业知识库、智能客服等场景，附完整部署教程与源码解析。

给 AI 装上 "记忆大脑"：Spring AI RAG 实战开源代码 —— 从 0 到 1 构建智能问答系统

解析特征向量核心原理，几何意义与特征值关系，附 Python 实战及跨领域应用指南。

特征向量入门：从线性变化到数据密码

本文全面解析 Gzip、Brotli、Zstd、Deflate 四大压缩算法，从依赖安装到场景落地全流程实战。涵盖 Node.js 与 Java 双端实现，详解压缩率、速度与兼容性对比，附完整代码示例、缓存优化及灰度回滚策略。助力开发者平衡延迟、CPU 与带宽，实现静态资源加速、微服务通信优化，成为 “带宽拯救者”。

压缩算法全家桶：Gzip/Brotli/Zstd/Deflate 从依赖安装到场景落地（Node.js & Java 实战指南）

本文详解 Java 中 Zstd 压缩与序列化的全流程实现，涵盖核心工具类开发、Redis 缓存 / 微服务通信等场景实战。解析压缩比与性能的权衡策略，提供基于场景的级别调优、字典优化等技巧，附完整代码示例与避坑指南。助力开发者通过 Zstd 实现高效数据存储与传输，平衡空间节省与处理速度。

Java端Zstd实战：序列化与反序列化全流程处理

深入解析分布式系统限流挑战与 Resilience4j 核心机制。本文详解 Resilience4j 的模块化设计、架构原理与六大核心模块（断路器、限流器、重试等），涵盖实战用法、源码剖析及自定义拓展。通过多模块组合最佳实践与监控集成方案，助你构建高弹性分布式系统，轻松应对高并发与故障场景。

分布式场景下限流算法的挑战与Resilience4j深度剖析

解析固定窗口、滑动窗口、令牌桶、漏桶 4 种经典限流算法，详解原理、公式、实现及选型，助你构建高并发系统流量防护体系。

深入剖析限流：从基础概念到算法实现

本文深入解析 Guava 组件中四种核心限流算法：固定窗口、滑动窗口、漏桶与令牌桶。从原理、数学公式、Guava 实现到优缺点与适用场景全面拆解，对比不同算法在高并发场景的表现，助开发者掌握流量控制关键技术，优化系统稳定性与资源利用率。

Guava 组件中的四种限流算法解析

本文是一份全面的响应式开发实践指南，聚焦 Spring WebFlux 与 Reactor 框架，从函数式编程基础（Lambda、函数式接口）切入，深入解析响应式流规范、背压机制及 Reactor 核心组件（Flux、Mono）。通过实战案例详解 WebFlux 的注解驱动开发、函数式路由、SSE 实时推送及 WebClient 使用，并对比传统 Spring MVC，分析响应式编程在高并发 I/O 场景的优势。适合 Java 开发者快速掌握异步非阻塞编程范式，提升系统吞吐量与稳定性。

响应式开发之WebFlux & Reactor：异步非阻塞编程实践指南

本文是一个向量数据库核心向量算法（kNN、HNSW、IVF_PQ、LSH 等）的数学公式与设计思路，对比主流数据库（Milvus、PgVector、Redis、Pinecone 等）的架构、算法支持、优缺点及适用场景。从算法原理拆解到选型决策指南，涵盖小数据轻量方案、高并发实时场景、大规模分布式部署等需求，帮开发者轻松搞定高维数据存储与相似检索，零基础也能看懂的向量数据库实战手册。

向量数据库全攻略：从算法公式到选型指南，一篇吃透高维数据存储术

本文以 “让异步编程像喝奶茶一样丝滑” 为理念，全方位解析 CompletableFuture 的核心原理与实战技巧。从 Java 异步编程进化史切入，对比传统 Future 的痛点，揭示 CompletableFuture 如何通过链式调用、灵活组合和优雅异常处理解决回调地狱。深入剖析其无锁状态机、Treiber 回调栈等底层设计，详解 thenApply、allOf 等核心 API 的使用场景。结合电商订单、数据聚合等实战案例，提供线程池隔离、超时控制、批量并行等高性能方案，配套可复用工具类。总结避坑指南与最佳实践，帮助开发者快速掌握异步编程精髓，提升系统并发能力与代码可读性。

CompletableFuture 从源码到实战：让异步编程像喝奶茶一样丝滑

本文是一份全面的 CompletableFuture 实战指南，从异步编程演进史切入，解析 Java 8 引入的 CompletableFuture 如何解决传统 Future 的回调地狱、组合困难等痛点。深入剖析其底层数据结构（volatile 结果存储 + Treiber 回调栈）与无锁状态机设计，揭秘 CAS 操作保障高并发性能的原理。系统梳理一元操作（thenApply/handle）、二元操作（thenCombine/applyToEither）、多元操作（allOf/anyOf）等核心 API，详解带 Async 后缀方法的线程控制策略。结合电商订单、数据聚合、支付多渠道等实战场景，提供线程池隔离、超时控制、批量分片等高性能方案。封装生产级工具类，涵盖结果聚合、异常处理、线程池管理等功能，并总结 8 大避坑指南，助力开发者轻松掌握异步编程精髓。

CompletableFuture 全景深度解析与高性能实践手册：从源码到业务落地

本文深入解析 Java 中强引用、软引用、弱引用、虚引用四种类型在 JVM 垃圾回收中的具体处理流程。强引用为默认引用，未断链时阻止回收；软引用在内存不足时被回收，适用于缓存；弱引用遇 GC 即回收，常见于 WeakHashMap；虚引用不影响对象生命周期，仅用于跟踪回收。通过对比四者的回收时机、对对象生命周期的影响及典型应用场景，帮助开发者理解 JVM 内存管理机制，优化内存使用，避免 OOM 与内存泄漏，提升 Java 程序性能与稳定性。

Java 四种引用类型详解：强 / 软 / 弱 / 虚引用在 JVM 垃圾回收中的处理流程与应用

全面解析 JetBrains 注解库的核心功能与实战价值。作为 Java 开发者解决空指针异常（NPE）的高效工具，其通过 @NotNull、@Nullable 等注解在编译期标记变量空状态，结合 IntelliJ IDEA 静态检查，将 NPE 风险提前暴露。文章详解 20 余种注解用法，包括 @Contract 方法契约、@TestOnly 测试边界等，搭配 MyBatis、Spring Web 等框架整合案例。同时提供团队落地六步法，从规范制定到 CI 集成，附代码评审清单与常见误区指南。助力开发者掌握编译期空安全策略，减少 90% 空指针事故，提升团队协作效率与代码质量。

 JetBrains Annotations：从入门到落地，彻底告别 NullPointerException

• 统一团队对代码元素空状态（参数、返回值、字段等）的声明方式，结合编译期与运行期校验消除NPE
• 规范主流框架注解（Jakarta Validation、MyBatis、Spring Web）的使用方式，提升代码一致性
• 明确各层代码契约（如接口参数校验规则、DAO层返回值约定），减少协作沟通成本
• 通过注解强化代码可读性与可维护性，降低后期迭代风险

 Java 注解规范模板

本文详解Java工程从规范到架构的完整链路，涵盖系统、模块、组件等核心概念辨析，助你厘清架构设计基础。包含Java工程规范全景图，解析4层架构（Controller/Service/Manager/DAO）的职责与边界，明确VO、DTO、DO、PO等领域模型的血缘关系及转换规则，提供类与方法命名的实操指南。还介绍从MVC到六边形架构的演进，结合美团、阿里等案例拆解微服务拆分原则与反模式，附工具链与自动化方案。帮你规避90%项目常见陷阱，快速落地规范与架构设计。

从规范到架构：一篇读懂 Java 工程建模、分层、命名与演进之路

本文记录了一次博客突发崩溃的排查与解决过程。作者在收到反馈博客无法访问后，通过多网络、多地域测试确认全网瘫痪。随后逐步排查，排除了 Vercel 部署平台和阿里云域名解析（含 DNS 污染）的问题，凭借其他使用又拍云 CDN 的站点也无法访问这一共性，锁定问题在又拍云。在其更新后陌生的界面中，逐个检查配置项，最终发现 HTTPS 配置里用了三年的自动续签证书消失，导致故障。作者通过在阿里云域名解析新增指向 Vercel 的记录，暂时恢复博客访问，并提交工单等待又拍云修复，同时复盘总结了抗风险经验。

博客突发崩溃？我的紧急排查与解决全记录

点开自己博客的友链页时，鼠标在屏幕上悬停了三秒。那些方方正正的卡片像排队的罐头，齐刷刷地陈列着，每个头像都带着同样的圆角，简介文字被框在固定尺寸的矩形里 —— 突然意识到，用 NotionNext 搭博客三年，居然让友链长成了这副模样。

友链这回事，总该有点温度

探索如何通过继承 Spring Cache 的 Cache 接口，以 RedisCache 为基础实现 BatchCache 扩展，深度解析 RedisCache 底层源码，详细讲解兼容 Spring Cache 规范的批量操作实现方案。涵盖 BatchRedisCacheWriter、BatchRedisCacheManager 等核心组件的完整代码实现，以及性能测试与优化策略。关键词：Spring Cache、Redis Cache、Redis 批量操作、Cache 批量操作。

Spring Cache 扩展：Redis 批量操作优化方案与 BatchCache 自定义实现

Moments 是一款极简朋友圈应用，自 v0.2.1 起采用 Golang 重写服务端，包体更小、功能更强。支持多用户模式、标签管理、图片上传（本地 / S3）、Markdown 语法，可嵌入网易云音乐、B 站视频及豆瓣内容，适配移动端与暗黑模式，用 SQLite 数据库便于备份。其页面经优化后，隐藏冗余元素，新增灵动岛歌词容器及炫光动画，歌词滚动更流畅。还实现 iPhone 16 Pro 模拟，通过精准尺寸计算、元素布局与交互设计，还原设备外观与灵动岛效果，支持播放器状态同步、歌词实时更新，适配无限滚动，提升用户交互体验。

🌟 探索 Moments 极简朋友圈： iPhone 16 Pro 模拟的深度优化

Spring AI高级RAG技术聚焦智能问答系统优化，核心组件包括MultiQueryExpander、RewriteQueryTransformer、CompressionQueryTransformer、ConcatenationDocumentJoiner、ContextualQueryAugmenter。基于LLM与向量检索技术，解决检索召回率不足、查询歧义、文档冗余等问题。适用于企业知识库（高精准需求）、客服对话（低延迟场景）等业务，通过查询扩展、改写、历史压缩、文档去重合并及上下文增强，构建高效RAG流水线，平衡精度与性能，提升生成质量，消除模型“幻觉”。

Spring AI RAG 高级检索增强：探索基于查询转换与文档处理的技术

Spring AI RAG检索增强生成实战：深度解析MultiQueryExpander、RewriteQueryTransformer、CompressionQueryTransformer、VectorStoreDocumentRetriever、ConcatenationDocumentJoiner、ContextualQueryAugmenter六大核心类源码，结合Redis向量存储、Spring Batch离线ETL、灰度发布与Prometheus监控，实现第一次会话高精准召回、多轮对话上下文压缩、去重合并与优雅降级，助力企业级Spring AI RAG知识库问答系统生产落地。

Spring AI RAG 检索增强实战：MultiQueryExpander+RewriteQueryTransformer+CompressionQueryTransformer打造高精准多轮对话知识库问答系统

Spring AI：以MultiQueryExpander与RewriteQueryTransformer重构RAG效能

Spring AI凭借模块化组件架构，成为企业级RAG解决方案的标杆。其核心优势由五大组件强势支撑：

MultiQueryExpander通过生成3-5个语义变体查询，较传统方案提升召回率40%+，精准覆盖专业术语多样场景；RewriteQueryTransformer结合上下文改写模糊表述，多轮对话歧义消除率达92%，彻底解决意图识别难题。

CompressionQueryTransformer实现60%历史压缩率，长对话响应延迟稳定在1.5秒内；ConcatenationDocumentJoiner以双轨去重（哈希/语义）清除30%-70%冗余，信噪比提升3倍。

ContextualQueryAugmenter动态优化检索质量，有效回答率提升25%，配合完善异常处理，杜绝"幻觉"与崩溃。Spring AI让开发者无需从零构建，快速部署高精准、强鲁棒的RAG系统，关键组件MultiQueryExpander、RewriteQueryTransformer等成为技术落地的核心引擎。

Spring AI 高级RAG检索增强生成优化指南： MultiQuery ，CompressionQueryTransformer，ConcatenationDocumentJoiner与文档处理提升检索精度与召回率

Spring Bean 机制作为 Spring 框架的核心，在复杂业务场景中发挥着关键作用。本文深入解析如何通过 Bean 生命周期、作用域、BeanPostProcessor 等核心特性，解决动态数据源切换、细粒度权限控制、复杂流程编排等实际业务难题。文中详细介绍了三大典型场景的解决方案：基于自定义作用域与 ThreadLocal 实现多租户动态数据源隔离，结合 BeanPostProcessor 与代理模式构建灵活的权限拦截体系，利用 FlowStep 接口与流程引擎完成可配置化业务流程编排。每个方案均包含完整代码实现、关键流程时序图及优缺点分析，深度融合 Spring Bean 的加载机制与生命周期管理。通过本文，开发者可掌握 BeanPostProcessor 动态注册 Bean、自定义 Scope 隔离业务上下文、利用初始化回调集成复杂逻辑等高级技巧，显著提升系统的灵活性、可扩展性与可维护性，为电商、金融等领域的复杂业务场景提供 Spring Bean 机制的最佳实践指南。

复杂业务场景下利用Spring Bean机制的设计与实践

本文深度剖析Spring Bean核心知识，涵盖Bean本质与容器关系、加载机制（扫描注册/实例化注入）、完整生命周期（11阶段）、5种作用域（单例/原型等）底层实现及条件注解、延迟加载等高级特性，助力掌握Spring Bean核心原理。

Spring Bean 源码深度剖析：生命周期、加载机制与作用域的底层实现

Spring中@Scope("prototype")与@RequestScope冲突解决方案：SEO友好摘要

在Spring开发中，@Scope("prototype")与@RequestScope是常用的作用域注解，但二者同时使用会引发严重冲突，导致实例复用异常、数据交叉污染或无请求上下文错误。本文深度解析两种作用域的底层机制，揭示其生命周期边界、实例管理逻辑及线程绑定的本质冲突，并提供7种实战解决方案：

1. 明确单一作用域：根据业务场景保留其中一个注解，避免语义冲突；
2. 代理注入模式：分离作用域职责，通过代理让原型Bean间接访问请求上下文；
3. @Lookup注解动态获取：在单例Bean中定义抽象方法，确保每次获取新原型实例；
4. 手动获取实例：通过ApplicationContext灵活获取不同作用域Bean，绕开注解冲突；
5. 自定义作用域解析器：根据Web/非Web环境动态切换作用域；
6. ObjectProvider延迟注入：在请求作用域Bean中安全获取原型实例；
7. 线程本地存储：手动管理上下文，适配异步等复杂场景。

本文还总结了作用域使用的7条最佳实践，帮助开发者理解Spring作用域设计原理，规避常见陷阱，确保Bean实例管理的可靠性。适用于Spring Boot开发者、Java后端工程师及架构师，解决作用域冲突导致的线上故障与性能问题。

深入排查:@Scope("prototype")与@RequestScope字段篡改问题全链路分析

Spring框架中，@Scope("prototype")和@RequestScope的冲突源于作用域语义的根本对立。prototype强调每次获取新实例，而RequestScope绑定请求生命周期。冲突表现为实例意外复用、数据污染或线程异常。本文提出7种解决方案：1)明确单一作用域；2)代理注入分离职责；3)@Lookup动态获取实例；4)手动获取绕过自动注入；5)自定义作用域解析器；6)ObjectProvider延迟获取；7)ThreadLocal手动管理上下文。最佳实践遵循单一职责原则，建议优先采用组合模式而非注解叠加，并强调理解作用域的生命周期边界是解决问题的关键。

Spring 作用域冲突深度解析：@Scope("prototype")与@RequestScope的冲突与解决方案

本文系统探讨了多线程编程在现代软件开发中的核心价值与应用策略。主要内容包括：多线程基础概念、线程池机制、并发冲突解决方案、业务开发全流程整合及函数式编程结合等。线程池通过资源复用和任务缓冲显著提升性能，但需根据任务类型(I/O/CPU密集型)合理配置核心参数。文章详细分析了线程泄漏、过载和死锁等常见问题，并给出针对性解决方案。特别强调线程池与业务需求的深度结合，从需求分析到运维监控的全流程管理。最后指出虚拟线程、云原生适配等未来趋势，建议开发者从小处着手，重视测试验证，持续学习新技术。多线程编程的核心在于找到性能与稳定、技术与业务之间的最佳平衡点。


Java 线程池与多线程并发编程实战全解析：从异步任务调度到设计模式落地，200 + 核心技巧、避坑指南与业务场景结合

本文深入解析Netty 4.1.x核心源码，揭示其高性能网络编程的实现原理。主要内容包括：1.启动流程分析：详细拆解ServerBootstrap初始化、Channel注册及端口绑定过程，展现主从Reactor模型的实现；2.线程模型剖析：深入EventLoop工作机制，包括事件循环、任务队列及JDK空轮询修复等关键技术；3.数据读写全链路：从客户端发送到服务端处理的完整流程，涵盖粘包拆包、编解码等核心环节；4.设计模式应用：责任链模式在ChannelPipeline中的实现，以及事件驱动模型的异步处理机制；5.性能优化细节：包括内存管理、零拷贝、线程模型优化等关键技术。文章通过时序图、场景分析和源码解读，为开发者提供Netty深度使用指南和架构设计参考。


Netty源码深度解析：从启动到数据流转的全链路剖析

MySQL底层核心技术解析与实践优化指南
本文深入剖析MySQL核心技术的底层实现，从B+树索引结构、事务与锁机制到查询优化器工作原理，提供系统级优化方案。主要内容包括：
1. 索引优化：详解B+树节点结构、插入/查询/删除流程，解析联合索引的最左前缀原则，指导高效索引设计。
2. 事务机制：深入MVCC实现原理，分析不同隔离级别下ReadView的生成逻辑，揭示Next-Key锁如何防止幻读。
3. 性能调优：基于代价模型解析优化器执行计划选择逻辑，提供慢查询优化方法论，包含典型案例分析（JOIN优化、排序优化等）。
4. 实践指南：总结表结构设计规范、SQL编写技巧及常见问题解决方案（如死锁处理、连接池配置）。
通过底层原理与工程实践的结合，帮助开发者构建系统的MySQL优化知识体系，实现从10秒到10毫秒的性能提升。

MySQL 底层技术深度解析：索引、事务、锁与优化全链路剖析

在软件开发的世界里，代码就如同城市的建筑，需要精心规划布局，才能高效运转。许多项目初期，开发者一心扑在功能实现上，代码一股脑堆砌，很快就陷入 “混沌”。想象一个没有分区规划的城市，商业区、住宅区、工业区混杂，交通拥堵，水电供应混乱。项目代码也是如此，业务逻辑、数据操作、用户交互代码交织，牵一发而动全身，修改一处功能，可能导致看似不相关的地方出错，排查问题像大海捞针，耗费大量时间精力。这类问题的根源在于代码职责不清晰。每个功能模块都承担过多任务，既处理复杂业务规则，又直接操作数据库读写，还负责与用户交互展示，就像一个人既要当厨师、服务员，又要做收银员，最终哪个角色都做不好。这种混沌状态下，代码难以理解、维护和扩展，成为项目持续发展的 “绊脚石”。

项目分层模块设计指南：让代码告别"一锅粥"，团队协作更丝滑

本文是2025年WebFlux实战指南，全面解析响应式编程框架Spring WebFlux在实际项目中的全方位应用。内容涵盖从环境搭建（核心依赖配置、生产级参数优化）到核心组件实践，包括基于Mono/Flux的控制器设计、过滤器链（请求日志、跨域、全局异常处理）、文件分片上传与断点续传，以及响应式数据库交互（R2DBC的实体映射、Repository接口、事务管理）。同时详解安全鉴权（JWT实现）、高并发限流（Redis令牌桶策略）、响应式缓存设计（Redis缓存管理器与注解使用）、远程调用（OpenFeign与WebClient对比）、MQ响应式集成（RabbitMQ生产者/消费者）、AOP切面增强及测试策略，并提供丰富代码示例与性能优化最佳实践，助力开发者掌握高并发、I/O密集型场景下的响应式编程技巧，构建高效可扩展的分布式系统。

WebFlux 实战指南 ：从入门到精通，环境搭建、控制器设计、数据库交互（含 R2DBC）到高并发优化（限流、缓存）的响应式编程全链路实践

作为一个每天和代码打交道的打工人，最头疼的莫过于提完MR后漫长的等待—— reviewer可能在开会、可能在改bug、可能在摸鱼，而你的代码只能在“进行中”状态里默默吃灰。更惨的是偶尔遇到“人工漏检”，上线后发现奇奇怪怪的bug，只能对着屏幕疯狂道歉：“这锅我背，下次一定仔细查！”

直到我发现了这个藏在云效里的神器——**yunxiao-LLM-reviewer**，现在我的MR终于有了一个24小时在线的“AI监工”，不仅能秒级反馈问题，还能把代码漏洞掰碎了讲给我听，甚至连摸鱼时都忍不住夸两句：这才是打工人的神仙辅助啊！

当我的代码评审开始 “AI 打工”：聊聊这个让我摸鱼更心安的神器

云效流水线Flow提供了灵活的集成机制，企业可以在云效Flow内开发一个自定义步骤来调用DeepSeek等大模型，对云效Codeup提交的代码评审进行智能评审，并通过云效的API，将这些评审意见回写到合并请求中。
同时，结合云效流水线Flow的能力还可以对提交的代码进行单元测试、代码扫描等任务，并将这些结果一并展示回云效Codeup的提交历史中，反馈每个commit的代码质量状态 
• AI 代码审查：使用大模型（Qwen、DeepSeek 等）对 MR 进行代码审查。
• 问题检测：聚焦于冗余代码、逻辑错误、潜在问题、SQL 性能优化等关键维度。
• 自动生成评论：根据模型输出的问题，自动在 MR 上提交评论。
• 支持多种模型：可选择不同的大模型进行代码审查。

云效Flow 自定义AI代码审核步骤

Java 多线程编程是 Java 开发中的核心技术之一，它涉及到线程基础、锁机制、线程间通信、并发工具类等多个方面的知识。通过深入理解多线程的核心原理，熟练掌握 JUC 包中的各类工具类和工具方法，结合线程池等技术，我们可以高效地解决各种复杂的并发问题，提升系统的性能和可靠性。在实际开发中，要根据具体的应用场景合理地选择和使用多线程技术，避免过度设计或滥用，从而实现高效、稳定的并发程序。

Java 多线程全文深度剖析

本文深入剖析了Spring Boot的加载与Bean处理过程，详细介绍了启动核心流程、Bean处理细节、优化策略等关键内容。从Bean的实例化、加载策略到依赖注入，再到优化Bean处理、配置文件加载、性能监控等多方面进行了全面探讨，并提供了具体的优化方法和实践建议，旨在帮助读者更好地理解和优化Spring Boot应用的启动过程与性能。

Spring Boot加载与Bean处理的细节剖析

本文系统分析并优化了一个Spring Boot项目启动耗时高达280秒的问题。通过追踪各阶段耗时、识别瓶颈、优化分库分表加载逻辑、异步初始化耗时任务等手段，最终将启动耗时缩短至159秒，提升近50%。文章详细介绍了启动流程分析、性能热点识别、异步初始化设计等关键技术细节，为大型Spring Boot项目性能优化提供了参考。


Spring Boot项目启动优化

本文将深入解析 Spring AI 中的 DocumentTransformer 和检索增强生成（RAG）模块，详细讲解每个核心类的功能、参数、使用方法以及高级技巧。通过结合实际代码示例和应用场景，帮助开发者全面掌握这些组件的使用。

Spring AI 中的 DocumentTransformer 与 RAG 深度解析

在当今数字化转型的浪潮中，人工智能（AI）技术正逐渐成为推动业务创新的关键力量。Spring AI 作为 Spring 生态系统中的一员，为开发者提供了一种简单而高效的方式来集成 AI 功能。作为一名专注于 Java 技术的开发者，我深入研究了 Spring AI 的架构、核心模块以及其实现方式，并在此分享我的学习心得和实践代码。

Spring AI 架构解析与核心模块实践

本条件表达式模块是流程引擎的核心决策组件，采用Spring Expression Language（SpEL）实现动态逻辑判断，支撑复杂业务流程的智能化路由。通过灵活的条件配置和强大的表达式解析能力，为企业级审批流系统提供高效、可靠的决策支持。

流程条件表达式技术方案

在Java开发中，我们经常需要对集合数据进行各种操作，比如批量获取用户信息、订单信息等。如果处理不当，很容易导致代码冗余、性能低下等问题。今天给大家介绍一个我最近发现的超实用的Java集合处理库——collection-complete。
collection-complete是一个用于处理集合数据并补充相关信息的Java库。它提供了链式调用的功能，可以方便地对集合中的元素进行批量操作和属性补充。这个库的设计理念是简化集合数据的处理流程，让开发者能够更高效地完成业务逻辑的实现。

一个超实用的Java集合处理库——collection-complete

在上一章NIO Channel篇中我们解释了它在NIO中的作用。Channel（通道）是一个核心概念，它提供了与IO设备（如文件、网络套接字等）进行数据传输的能力。下面我将从多个方面详细讲解NIO的Channel。Channel本身不直接存储数据，它通过与Buffer（缓冲区）的交互来实现数据的读写。数据首先被读入到Buffer中，然后再从Buffer中写入到Channel，或者从Channel读入到Buffer。
Channel的工作原理
• ‌与Buffer的交互‌：Channel本身不直接存储数据，它通过与Buffer（缓冲区）的交互来实现数据的读写。数据首先被读入到Buffer中，然后再从Buffer中写入到Channel，或者从Channel读入到Buffer。
• ‌非阻塞模式‌：Channel支持非阻塞模式，这意味着线程可以在等待IO操作完成时继续执行其他任务，而不是被阻塞。这大大提高了程序的并发处理能力。
• ‌Selector机制‌：NIO还提供了Selector机制，它允许单个线程同时处理多个Channel的IO事件。Selector会不断地轮询注册在其上的Channel，检查是否有IO事件发生，并通知相应的线程进行处理。

Java IO — NIO Channel

在上一章中我们介绍的 NIO模型的核心组件 以及其运行流程
知道如何简单使用 buffer 之后，下面就来探究一下 buffer 的底层原理。
Buffer 的原理主要在于它的四个属性：
• mark：在缓冲区操作过程当中，可以将当前的 position 的值临时存入 mark 属性中，需要的时候再取出，恢复到之前的 position，重新从之前的 position 位置开始处理。调用 mark() 方法来设置 mark=position，再调用 reset() 可以让 position 恢复到 mark 标记的位置，即 position=mark
• position：位置，读或写都会改变位置
• limit：表示缓冲区的当前终点，不能对缓冲区超过极限的位置进行读写操作，极限可以修改
• capacity：容量，在缓冲区创建时设定且不可修改，比如前面创建的缓冲区容量就是 1024 且不可修改

Java IO — NIO Buffer

在Java中，IO（输入/输出）操作是核心组成部分，尤其是在网络编程和文件操作中。随着Java的发展，IO模型也在不断进化，以适应不同的应用场景和性能需求。本文将详细介绍Java中的三种主要IO模型：阻塞IO（BIO）、非阻塞IO（NIO）和异步非阻塞IO（AIO）。

Java IO — IO/NIO模型

在Elasticsearch中Mapping Index是一个核心概念，它定义了索引中数据的结构，包括字段的名称、类型、属性等。用于定义索引中文档及其字段如何被存储和索引的过程。它类似于传统关系型数据库中的表结构定义。在 MySQL 中，表结构里包含了字段名称，字段的类型还有索引信息等。在 Mapping 里也包含了一些属性，比如字段名称、类型、字段使用的分词器、是否评分、是否创建索引等属性。
‌作用‌：
• 定义索引下的字段名（Field Name）。
• 定义字段的类型，如文本型（text）、关键字型（keyword）、数字型（integer、long、float、double等）等。
• 定义字段的索引相关配置，如是否索引、是否记录位置信息等。

Elasticsearch — 索引（Mapping Index）

Elasticsearch是一个基于Lucene分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间数据等。它构建于Lucene之上，并提供了一个易于使用的RESTful API来处理数据索引和搜索。Elasticsearch以其强大的全文搜索能力而闻名，并且能够实时地存储、搜索和分析大量数据。此外，Elasticsearch还常常与Logstash（用于收集、解析和处理数据流）和Kibana（用于数据可视化）结合使用，形成了ELK Stack，广泛应用于日志分析、指标分析以及其他大数据应用场景中。
在实际业务场景中我们或许是因为数据库中数量大且需要一个复杂的条件过滤时才考虑到应用Elasticsearch，因为它提供大数据量（PB）近乎实时的搜索功能。

Elasticsearch — 如何存储数据并保持一致性？

上文我们介绍了Java比较算法的核心思想 但那仅仅是最简单的思维方式并不是大家最常用下面我们来学习下组合了集中思想的快速排序算法。快速排序（Quick Sort）是一种高效且广泛应用的排序算法，由东尼·霍尔所发展，并于1960年由C.A.R.Hoare提出。快速排序是对冒泡排序的一种改进，它采用分治法的策略来将一个序列（或数组）分为两个子序列，并通过递归的方式对这两个子序列进行排序，从而达到整个序列有序的目的。通过选取一个基准值（pivot），将待排序的序列分为两部分，一部分包含所有小于基准值的元素，另一部分包含所有大于基准值的元素（相等的元素可以归到任一边）。然后，递归地对这两部分继续进行快速排序，直到整个序列有序。在Java中List接口中实际应用了该算法，也是我们最常使用的算法之一。本文介绍了Java中的快速排序和归并排序算法，包括其实现细节和优化策略。快速排序使用三向分区方法进行排序，而归并排序利用分治策略进行合并。还讨论了Timsort算法的执行过程和关键阀值，以及如何在Java中对List集合进行排序。Timsort结合了归并排序和二分插入排序的优点，适用于大数据集的排序。

Java算法 — 快速排序（Quick Sort）

比较排序（Comparison-based Sorting）是一种基于元素之间比较操作的排序算法。这类算法通过比较数据之间的大小关系来确定数据的相对顺序，从而完成排序。在我们学习Java算法过程中是一个比较重要的一个排序算法，下面我讲从一些基础简单算法 它们不是最好的算法但是其中的核心思想和思维模式值得我们深入学习。其实有 选择排序（Selection Sort），插入排序（Insertion Sort），冒泡排序（Bubble Sort），归并排序（Merge Sort），堆排序（Heap Sort）

Java算法 — 比较排序（Comparison-based Sorting）

上一小节我们总结了Reactor模型，Netty基于主从Reactor模型设计了自己的模型结构，使得Netty在不同的场景下都有非常亮眼的性能和可用性表现。进入到这一小节，我又想到了那句话”Talk is cheap, show me code”。虽然上一小节我们简单写了一个“快速开始”，但是这对于要达到快速使用Netty进行网络开发的目的还远远不够。在一小节中我们会通过一系列的Demo示例熟悉Netty的开发，从代码中感受他们的特性。最后我们会通过一个简单的聊天加深我们对Netty各个核心组件的理解。最后我们动手设计实践一个API网关，认识网关的功能和结构，同时也进入提升我们使用Netty进行网络开发的熟练度，同时为后续深入源码打下基础。这一小节代码比较多，不要害怕耐心看完并付诸实践，一定会收获满满。

Netty — API网关Demo

前面几个小节，我们梳理了几个核心组建，深入的分析了这几个组建的工作原理和一些实现细节，但是细看局部总是难以获得一个全局的视角，很难把它们真正的串起来。在梳理完这几个组件之后，我最想知道的就是启动的时候和读写操作的时候，这几个组件是怎么配合工作。虽然我也看过一切流程图，和一些简单的总结，但是自己没有深入过源码总感觉缺了点什么。我相信只有真正分析调试过源码才能真正理解，各个组件之间是怎么协作的，各个组件之间的设计要点是什么了。带着这些疑惑，我深入了源码也收获颇丰。这个部分，我们将对Netty的启动过程进行深入的分析，看看Netty是如何进行注册、绑定和监听。

Netty流程剖析 — 服务启动源码

在上一小节中，我们介绍channel，channel 的主要功能有处理网络IO读写，处理连接。这里需要注意的是channel仅仅是负责读写操作，在NIO中真正负责传输数据的是Buffer（缓冲区）。在NIO中，缓冲区的作用也是用来临时存储数据，可以理解为I/O数据的中转站。缓冲区直接对接channel，为其提供写入和读取的数据。通过操作buffer批量进行数据传输提高效率。在NIO中主要有八种缓冲区(ByteBuffer、CharBuffer、ShortBuffer，IntBuffer、LongBuffer、FloatBuffer、DoubleBuffer)。在网络中传输中，字节是基本单位，NIO使用的ByteBuffer作为Byte的字节容器，但是NIO中实现过于复杂，因此Netty又写了一套ByteBuf来代替NIO的ByteBuffer，这一小节我们将深入ByteBuf源码，探究ByteBuf底层原理与实现细节。

Netty核心组件源码剖析 — ByteBuffer

上一小节我们梳理了NioEventLoop，通过梳理我们知道，NioEventLoop本质上就是封装的执行线程，线程通过NioEventLoopGroup构造创建。NioEventLoop通过select()方法监听selectKey触发对应连接，读/写事件。并在每次的循环中执行一定的任务队列中的任务。而每次事件的触发都是基于Channel实现的。这里的Channel不是NIO中的Channel，而是我们Netty中封装了NIO Channel实现的Channel。这一小节我们将深入理解Channel的一些功能原理和具体的一些实现细节。

Netty核心组件源码剖析 — Channel

我们的源码分析会围绕着《Netty源码剖析与应用》这本书来学习，并且结合自己分析看源码，毕竟只有自己看到才是真的。这一小节我们要分析梳理核心组件NioEventLoop的源码，从源码角度看看NioEventLoop到底做了哪些事。第一次深入的研究源码学习，源码看得的确挺头大的，但是通过源码角度对Netty又有了一个全新的认知收获很多，那我们就一起来分析以下NioEventLoop吧。

Netty核心组件源码剖析 — NioEventLoop

socket网络编程和IO模型，这一小节我们来入门Netty。对于很多程序员来说，Netty是非常遥远的。很多程序员认为平时的开发过程中基本不会使用到Netty，如果你也是这么认为的那就大错特错了。因为我们虽然不会直接写Netty的代码，但是我们每天都在间接使用Netty，大到我们的RPC框架dubbo、大数据的Hadoop，小到Redis的工具包，几乎所有实现网络通信的框架都是基于Netty实现的。所以学习Netty掌握Netty不论是对于我们来说都是开发网络程序，还是排查网络问题，亦或是框架设计思想上的提升都有莫大的帮助。这一小节我们先从最基本的Netty的结构模型开始，先建立一个Netty的基本的认知，随后我们编写Netty的HelloWorld加深对Netty的一些模块点的理解

网络编程 — Reactor模型与Netty

网络的基础知识包括一些网络模型和协议。我们常说Talk is cheap, show me code.这一小节我们将解锁Socket网络编程，通过Socket来编写简单一些简单的网络小程序。我很早之前就接触过Socket网络编程，也能写一些简单的程序，但是始终感觉socket离我很遥远，不清楚socket到底是什么以及socket是如何工作的。如果你也有和我一样的疑问，通过这一小节的梳理让我们一起搞懂socket，解锁socket技能点。在编写完socket程序之后，我们还会思考如何提高我们socket网络程序的处理吞吐量连接数，并且引入我们的IO模型，深入理解几种常见的IO模型。

网络编程 — Socket编程与IO模型

网络模型和一些网络协议，其中最大头TCP协议我们挖了一个坑，这一小节我们来填坑。这一小节我们主要分成三大块，第一部分我们将介绍，TCP的三次握手和四次挥手，通过简单的交互维护一个状态机之后建立一个稳定可靠的连接。我们有了一个稳定的连接，我们还需要数据包地稳定发送和接收。有了上面两个保障之后，如何充分利用网络带宽，成了最后的问题，这里我们介绍了传统算法和BBR算法。梳理完以上这些部分，我相信你对TCP协议会有更加深入的理解，让我们先从TCP的介绍开始吧～

网络基础 — 深入理解TCP协议

网络对于程序员非常重要，可以说离开了网络软件程序就失去了70%的魔力。但是程序员对于网络相关的领域是又爱又恨，爱是因为网络赋予程序无限的可能性，恨是因为网络对软件开发来说几乎是透明的，不用刻意的去调整网络，我们也能进行业务的开发。掌握网络相关的知识并不容易，网络相关的领域的知识内容复杂且涉及范围广。可是如果要成为一个优秀的开发工程师，进行网络相关的开发，就必须对这个部分有一个清晰的结构化的认知。这一小节，我们会从网络的TCP五层模型和OSI七层结构模型开始梳理介绍，随后介绍每一层和每一层具有代表性的网络协议，最后我们简单的聊一聊一个数据包是怎么在网络上传输的。

网络基础 — 网络模型与网络协议

前面一小节中，我们梳理了经典的垃圾收集器。从单线程的Serial串行垃圾收集器开始，聊到了CMS最后到G1，并着重的分析了CMS和G1并发垃圾收集流程和部分实现原理。这些垃圾收集器经过数千台服务器的验证淬炼，已经变得相当的成熟可靠，但是真的就是完美的垃圾收集器吗？答案是否定的。今天我们一起来看看相较于“经典”垃圾收集器的全新一代垃圾收集器 Shenandoah 和 ZGC。这种垃圾收集器能够实现超大堆的容量下，轻松实现垃圾收集停顿不超过10ms的目标，但是目前还处于实验状态，官方命名为“低延迟垃圾收集器”（Low-Latency Garbage Collector 或者 Low-Pause-Time Garbage Collector）。

JVM GC篇 — 垃圾收集器（下）

前面一小节我们介绍了介绍了GC的一般性原理和垃圾回收算法，通过对前面知识的学习，我们基本掌握了垃圾收集的一般理论知识。但是理论终究知识在之上，距离真正的实践还有一定的差距。前面我们提到了第一个带有内存动态分配和垃圾收集的编程语言并不是 Java 而是1960年诞生的Lisp。当然这一小节中我们并不会梳理 Lisp 实现的垃圾收集器。这一小节我们会先从经典垃圾收集器入手，梳理各个垃圾收集器的特性、优缺点和适用场景。当然随着垃圾收集器的效率的不断提升其实现的复杂度也在不断提升。我们会主要的篇幅去介绍CMS和G1原理及部分实现细节，升华对垃圾收集器的理解。今天是六一儿童节，各位朋友坐好来，我们的梳理开始了。

JVM GC篇 — 垃圾收集器（上）

我们都知道 Java 程序员不用像 C++ 程序员一样手动申请和释放对象空间，这是因为 JVM 垃圾回收器的存在。为什么需要垃圾回收呢？因为空间是有限的，而我们运行程序完成各种各样的计算需要申请空间。但是空间不是无限的，如果我们的空间不够申请怎么办？这个时候就要释放内存，删除掉一些不用的无效的空间，来腾出空间来创建我们需要的对象。这就像我们的衣柜一样，我们买衣服回来放在衣柜里面，但是衣柜不是无限大的，所以当衣柜放不下的时候，我们就要清理丢掉小了的或者我们不穿的衣服，这样为新的衣服腾出空间。Java 自带GC会自动清理内存空间，而C++这种没有GC的语言，就需要使用手动清理空间了。全自动不用程序员操心的确很好，如果放仍不管也会引起其他的问题，那么怎么清理起来才是正确且高效。这就是一个有意思的问题，这一小节我们将从 GC 的一般原理和垃圾回收算法开始，逐步展开 Java GC 的世界。

JVM GC篇 — 一般原理与垃圾收集算法

在前面的小节中，总结梳理了 JVM 底层的一些基础的东西，包括 JVM 字节码技术，方法的调用，反射，异常等方法流程，基础的最后一部分梳理了类加载机制和对象的内存布局。有了这一套机制 JVM 能够顺利的读取Java文件，并行执行逻辑。看起来都有了，但是少了一个重要的部分没错，就是内存。这计算机的内存这个部分来的像理所当然一样。其实最原始的计算机是没有内存这个概念的，后来冯诺依曼提出了冯诺依曼结构，冯诺依曼确定了计算机的结构，即确定了计算机的 5 大部件，即运算器、控制器、存储器、输入设备和输出设备。现代计算机的都是遵循冯诺依曼结构的，因此又称为冯诺依曼机。所以作为虚拟机怎么能没有内存呢？Java 内存模型规定了 JVM 应该如何使用计算机内存（RAM）。广义上来讲，Java内存模型分别为两个部分 JVM内存结构 和 JMM与线程规范。

JVM基础 — 内存结构与内存模型

在前面一篇中提到了方法的调用，方法在类加载阶段会由符号引用替换实际引用或者方法表的索引。Java 的类加载机制又是怎么样的呢？我记得我刚毕业那会去面，基础的问题都回答的挺好的但是最后面试官问了我这个问题，Java 虚拟机是怎么加载一个类的？我当时脑子懵了，对象怎么加载到内存？对象是 new 出来的的啊，还要加载？我也对这块不太了解，然后面试官也就没深了问。但是现在看来，如果是进阶 Java 的话这是一个基础不能在基础的问题了。类加载了这还不算完，Java 的类是怎么保存的，我相信很多朋友会回答存放在堆里，那其他特殊的类型呢 例如 String 类型又是怎么存储的呢？我们在内存溢出的时候，对象怎么就把我们的堆给堆满了，每个对象占了多大的空间呢？请朋友们慢慢往下看。

JVM 基础 — 类加载机制和对象内存布局

在前一篇中简单介绍了Java 字节码中有关方法调用的一些操作码，但是 java 方法的调用往深了讲又有很多的门道，简单的有方法的重写和重载，深入也有方法的动态绑定和静态绑定，那JVM是如果识别和选定方法的呢？还有有些时候我们并不能直接调用某个目标方法，而是要使用一些特别的手段去调用，也就是我们会经常用到的反射，反射不同于常规的方法调用，这货一上来就不走寻常路，一般方法调用都是先 new 一个对象，就像是朋友来家里做客从正门进来，反射是先通过 class 对象找到目标方法然后传入调用实例，这更像是翻墙进来。那这个翻墙进来的它背后的原理又是怎样的呢？假如这个世界是美好的，但一个方法的执行可能没那么顺利，万一发生了异常这个异常又是怎么捕获的呢？

JVM 基础 — Java 方法调用、反射调用与异常

我们通常表述的 JVM 通常有三种意思，JVM 是 Java virtual machine 即 java 虚拟机的缩写，也就是我们通常所指的 JVM。JVM还是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。因此 JVM 也是图灵完备的。当然 JVM 还可以表示一个虚拟机的实例。Java 一个非常重要的特性就是和平台无关，而 JVM 是实现这一点的关键。JVM 底层使用 C 进行编写，只要平台能执行 C 语言，这也就能启动 JVM 运行 Java 程序。JVM 通过编译 Java 语言生成字节码文件，字节码文件在通过 JVM 进行解释执行。因此只要运行在不同的平台上的JVM 能拿到字节码文件，就能解释执行出相同的结果。这就是 Java 可以 “一次编译，到处执行” 的原因。

当然并不是Java 语言是跨平台的语言，拿 C++ 举个例子，C++ 也是一门跨平台的语言，但是和 Java 语言不同的是，C++ 需要到不同的平台生成不同的文件，然后进行执行，也就是源码跨平台，而 Java 是二进制跨平台。

JVM 基础 — Java 字节码

异步执行对于开发者来说并不陌生，在实际的开发过程中，很多场景多会使用到异步，相比同步执行，异步可以大大缩短请求链路耗时时间，比如：发送短信、邮件、异步更新等，这些都是典型的可以通过异步实现的场景。1. 线程Thread
2. Future
3. 异步框架CompletableFuture
4. Spring注解@Async
5. Spring ApplicationEvent事件
6. 消息队列
7. 第三方异步框架，比如Hutool的ThreadUtil
8. Guava异步

Java异步编程方式介绍

常见的技术选择包括：
• 数据库级多租户：使用多个数据库实例分别存储各个租户的数据，每个租户对应一个独立的数据库。
• 模式级多租户：使用同一个数据库实例，但是为每个租户创建独立的数据库模式，实现数据隔离。
• 表级多租户：在同一个数据库模式下，使用不同的表来存储各个租户的数据，实现数据隔离。
• 应用级多租户：在应用程序中实现租户隔离，例如使用Spring Cloud等微服务框架。
• 容器级多租户：使用容器技术，为每个租户创建独立的容器，实现资源隔离和控制。
4 实现多租户架构的注意事项
• 保证租户数据的隔离性和安全性。
• 设计合理的租户数据结构和关系模型。
• 统一管理租户的配置和权限。
• 保证系统的可扩展性和可伸缩性，支持水平扩展。
• 保证系统的高可用性和容错性，避免单点故障。
• 对租户数据进行备份和恢复，保证数据的可靠性和完整性

Spring Boot 实现多租户架构：支持应用多租户部署和管理

微服务，顾名思义，就是将我们程序拆分为最小化单元来提供服务。在一体化系统中，各个微服务也是不可能独立存在的，那么微服务之间涉及到的数据依赖问题，应该怎么处理呢？我们从场景入手来分析考虑此类问题。

微服务之间的数据依赖问题，该如何解决？

做一些C端业务，不可避免的要引入一级缓存来代替数据库的压力并且减少业务响应时间，其实每次引入一个中间件来解决问题的同时，必然会带来很多新的问题需要注意，比如缓存一致性问题。
那么其实还会有一些其他问题比如使用Redis作为一级缓存时可能带来的热key、大key等问题，本文我们就热key（hot key）问题来讨论，如何合理的解决热key问题。

Redis 热key是什么问题，如何导致的？有什么解决方案？

Spring 框架一直提供了两种不同的客户端来执行 http 请求:
• RestTemplate: 它在 Spring 3 中被引入，提供同步的阻塞式通信。
• WebClient: 它在 Spring 5 的 Spring WebFlux 库中作为一部分被发布。它提供了流式 API,遵循响应式模型。
RestTemplate 的方法暴露了太多的 HTTP 特性,导致了大量重载的方法，使用成本较高。WebClient 是 RestTemplate 的替代品,支持同步和异步调用。它是 Spring Web Reactive 项目的一部分。
现在 Spring 6.1 M1 版本引入了 RestClient。一个新的同步 http 客户端,其工作方式与 WebClient 类似,使用与 RestTemplate 相同的基础设施。

HttpClient? RestTemplate？WebClient? 不~是 RestClient

Hutool是一个小而全的Java工具类库，通过静态方法封装，降低相关API的学习成本，提高工作效率，使Java拥有函数式语言般的优雅，让Java语言也可以“甜甜的”。 JavaBean是一个拥有对属性进行set和get方法的类。它可以被简单地定义为包含setXXX和getXXX方法的对象。在Hutool中，判定Bean的方法为：是否存在只有一个参数的setXXX方法。Bean工具类主要操作setXXX和getXXX方法，如将Bean对象转为Map等。

Hutool 5.8.8  BeanUtil.copyProperties 致命异常

Red Hat SSO (或Keycloak)是领先的Web SSO产品之一，支持SAML 2.0、OpenID Connect和OAuth 2.0等标准，强大之处在于可通过多种方式直接访问Keycloak，包括API调用生成和验证JWT令牌。操作仅限API调用，无需暴露Keycloak的UI给公众。

使用 Keycloak 的 API 登录和 JWT 令牌生成

Keycloak REST API 可以被用来进行身份验证和授权。使用该API，开发人员可以轻松地在其应用程序中实现安全性验证和授权功能，同时使用Keycloak的内置功能进行管理和配置。Keycloak的REST API还提供了许多不同的终端点来进行用户和角色管理、认证事件和SAML元数据的访问等。 作为一个基于开源的身份和访问管理解决方案，Keycloak的REST API对于任何需要对应用程序进行认证和授权的开发人员都非常有帮助。