jakeswang的博客

回过头来看，AI Coding 带给我们的，其实不是“程序员被替代”的焦虑，而是一次角色升级的机会。架构设计、需求拆解、规范制定、质量把控。这些才是技术工作中更有价值的部分。

AI客服Agent生产环境灾难与解决方案 摘要：文章剖析了一个AI客服Agent上线后引发的三个P0级事故：财务误退款、情绪化回击客户、接口死循环调用。针对这些事故，提出了关键解决方案：1)对退款等敏感操作设置前置条件和后端校验；2)建立输出审查层拦截不当内容；3)实施物理熔断机制防止死循环。最后总结出四大生产级工程规范：二次确认机制、后端强校验、输出内容审查、全链路追踪与熔断。这些措施旨在将大模型应用控制在安全可靠的框架内，避免生产环境中的灾难性后果。

在 Cursor 的设置里，添加团队的代码规范、架构规范、常用的技术栈作为全局指令，比如 “所有接口必须返回统一的 Result 格式，使用 SLF4J 日志，禁止使用 System.out.println”，AI 生成的代码会自动符合规范，减少后续的修改成本；

CompletableFuture.runAsync()执行时出现ClassNotFoundException的根本原因是异步线程的类加载器与主线程不一致，导致无法加载任务依赖的类。主要场景包括： 类加载器上下文不匹配（最常见） 序列化/反序列化问题 依赖类缺失或冲突 线程池配置不当 解决方案： 在异步任务中手动设置线程上下文类加载器 使用自定义线程池并指定类加载器 避免跨环境序列化任务 检查依赖和打包配置 最佳实践是通过代理层集中处理类加载问题，同时实现日志、容错等增强功能。该问题本质是类加载隔离导致的，

摘要：文章分享了Java开发中JVM参数调优的实战经验。通过一个线上系统内存溢出案例，详细介绍了四步调优方案：1)优化内存分配策略；2)升级GC算法并调优；3)诊断内存泄漏；4)治理元空间和堆外内存。调优后系统性能显著提升，FullGC频率从每分钟3次降至每天1-2次。文章还提供了容器化环境的特殊配置建议，强调调优要基于数据监控，遵循"一次一变"原则。最后总结了排查清单和常见JVM参数配置要点，包括堆内存、直接内存、代码缓存等关键参数的优化方法。

Redis常见问题与优化方案 摘要：针对Redis使用中的常见问题，本文总结了10类典型场景的优化方案： 1.内存优化：设置自动过期、清理僵尸key、合理淘汰策略 2.CPU优化：禁用慢命令、主从分离、关闭非必要功能 3.大key处理：拆分key、使用unlink删除 4.模糊查询：使用scan代替keys 5.持久化平衡：合理配置RDB/AOF参数 6.主从同步：设置写入条件避免脑裂 7.集群扩展：分槽存储扩容方案 8.缓存问题：应对穿透、击穿、雪崩的方案 9.监控优先：先分析再优化 10.简单优先：先尝

本文深入探讨了分布式系统中的核心挑战——数据一致性，重点分析了分布式锁的实现与优化方案。首先介绍了基于Redis的分布式锁基础模型（SETNX+DEL），并指出其存在的问题：死锁风险、锁等待策略、锁续约机制等。随后详细讲解了锁续约（看门狗机制）和原子化释放锁的实现方法。在高阶方案部分，介绍了Redlock算法及其主从复制问题解决方案，并讨论了性能优化策略如Singleflight模式和本地锁交接。最后指出分布式锁并非万能，可考虑乐观锁、一致性哈希等替代方案。文章强调分布式锁设计需要平衡可靠性与性能，理解其背

于是，官方陆续的发布了几个对应 JDK 的修复版本，其中针对 Java 25，发布的是 JDK 25.0.1。你看，官方评估过后，考虑到严谨性，首选的方案竟然是回退版本。最后，切记，最先吃螃蟹是有风险的，即使在进行 JDK 升级时，也尽量做到充分的测试和评估是避免生产环境问题的关键。另外JDK 25 作为最新的长期支持（LTS）版本，虽然带来了许多令人兴奋的新特性，但也引入了一些需要特别注意的。这个紧凑的内存布局，短了一字节，也短了命，让 JDK 25 的“字节”级事故坑到了不少老外尝鲜的网友。

摘要：ServletLess（Serverless）架构正改变应用构建方式，让开发者专注业务逻辑而非基础设施。本文对比了传统架构与ServletLess的核心差异，详细解释了其事件驱动、弹性伸缩和按量付费的特点。通过AWSLambda搭建图片处理服务的实例，展示了从环境配置到部署测试的全流程。特别探讨了ServletLess与AI结合的潜力，如异步推理、智能客服等场景。针对现有SpringCloud系统的改造，提出了三种策略并着重介绍了基于SpringCloudFunction的平滑迁移方案，涵盖依赖调整、

Jenkins作为传统CI/CD工具正面临性能瓶颈、插件维护困难、云原生支持不足等挑战。相比之下，GitHub Actions凭借与GitHub生态深度集成、YAML配置简单、原生支持多平台和容器等优势，成为现代化替代方案。文章详细对比了两者差异，并提供了从Jenkins迁移到GitHub Actions的具体方法，包括配置转换示例和迁移工具推荐。随着云原生技术发展，GitHub Actions等新型工具更符合现代开发需求，建议开发者尝试迁移以提升CI/CD效率。

Java 25 LTS版本发布，带来多项现代化改进。核心更新包括：1）语言简化（实例主方法、模块导入等降低入门门槛）；2）性能优化（紧凑对象头、分代Shenandoah GC）；3）并发增强（结构化并发、作用域值提升线程安全）；4）AI支持（向量API加速计算）；5）安全性提升（内置PEM编解码）。版本聚焦开发效率、运行性能和现代化特性，使Java更简洁、安全、高效，既降低新手学习成本，又满足企业级应用需求。

Sensitive 是一个基于 Java 注解的日志脱敏工具框架 ，由 houbb 开发，它就像是一个细心的信息守护者，默默地为 Java 应用的日志处理加上了一层安全锁。通过简单易用的注解，它能够在日志记录的过程中，精准地识别出敏感信息，并按照预设的规则进行脱敏处理，从而有效地保障用户隐私和数据安全，为我们的应用程序保驾护航。接下来，我们以一个用户实体类User为例，来看看如何使用注解标记敏感字段。

JDK21虚拟线程与Go协程对比：Java虚拟线程通过自动挂起机制提升I/O密集型任务吞吐量，适合企业级应用；Go协程凭借轻量级调度在CPU密集型任务和云原生场景表现优异。Java生态更成熟，Go语法更简洁。选择取决于项目需求：复杂业务选Java，高并发云服务选Go。两者可混合架构，优势互补。

摘要： Java 21作为2023年LTS版本，在并发编程、语法简化等方面带来革命性升级。核心特性包括： 虚拟线程：轻量级并发模型，支持百万级线程创建，显著提升I/O密集型任务吞吐量； 模式匹配增强：支持switch模式匹配与嵌套Record解构，代码更简洁； 分代ZGC：降低GC停顿时间，优化大堆内存管理； 统一集合API：新增SequencedCollection等接口，规范有序集合操作。 相比Java 8，Java 21在开发效率、性能和安全性上均有质的飞跃，建议优先学习虚拟线程等关键特性，逐步迁移至

摘要：本文系统总结了四种缓存更新模式及其适用场景。1）旁路缓存（Cache-Aside）：先查缓存后查DB，更新时先更新DB再删缓存，热点数据可预刷新；2）异步写回（Write-Back）：先写缓存后异步更新DB，适合高QPS场景；3）穿透模式（Read/Write-Through）：由存储服务维护缓存一致性，实际应用较少；4）持续优化方案：多级缓存、异构数据、逻辑过期等。核心建议：大部分场景使用旁路缓存，热点数据预刷新；高并发场景采用异步写回；强一致场景直接查DB。系统设计需结合业务特点进行优化。

本文对比了MyBatis-Plus和MyBatis-Flex两大MyBatis增强框架的核心能力与实战应用。测试显示MyBatis-Flex查询性能略优（快10%左右），内存占用更低；MyBatis-Plus插件生态更丰富。MyBatis-Plus采用接口继承方式实现CRUD，学习成本低；MyBatis-Flex通过APT生成代码，支持更灵活的DSL查询语法，在多表关联场景优势明显。选型建议：追求稳定性和插件生态选MyBatis-Plus，需要处理复杂查询或注重性能选MyBatis-Flex。迁移时可采用渐

摘要：Spring Cloud Feign是一个基于动态代理的声明式HTTP客户端，通过注解简化微服务间调用。其工作原理包括：1）启动时扫描@FeignClient注解生成代理对象；2）解析方法注解构建HTTP请求；3）通过底层HTTP客户端（可配置）发送请求；4）集成负载均衡和服务发现；5）支持熔断降级机制。相比直接使用RestTemplate，Feign使代码更简洁、易维护，支持类似本地方法的远程调用方式，并提供了超时配置、日志等特性。核心优势在于将HTTP调用封装为接口方法，结合Spring生态实现完

本文分享了作者在负责高并发系统时应对十万级QPS的实战经验。通过地图导航业务场景，详细介绍了系统架构设计、数据库选型（选择HBase）及性能优化过程。重点解决了读放大问题，采用"大布隆+小布隆"过滤器的创新方案降低数据库压力，并通过本地缓存解决节假日热点问题。文章强调技术方案需结合实际业务场景，深入理解技术细节才能有效应对高并发挑战，而非单纯背诵八股文。作者用亲身经历证明十万QPS并非噱头，合理的缓存设计对业务稳定性至关重要。

【Redis海量数据筛选方案】在处理2亿个key中筛选20w特定后缀key时，KEYS命令因全量遍历会导致服务阻塞，严禁生产使用。推荐方案：1）使用SCAN命令配合游标分批扫描，通过MATCH匹配后缀和COUNT控制批次，实现非阻塞查询；2）高频需求建议采用Set集合构建索引，写入时同步维护索引集合；3）低频离线操作可在从节点执行。架构层面优化优先考虑事前索引，避免事后全量扫描。SCAN方案示例代码展示了安全的分批扫描实现方式。

本文记录了一次线上频繁FullGC问题的排查过程。系统在升级后出现每分钟超过5次FullGC的异常情况，通过分析GC日志和内存快照，发现是由于Log4j2配置不当和JVM参数设置问题共同导致。根本原因是系统误引入Servlet依赖，导致Log4j2线程缓存失效，每次日志打印都创建2MB的StringBuilder对象，加上JVM参数"-XX:PretenureSizeThreshold=2097152"的设置使这些大对象直接进入老年代，快速填满老年代空间。解决方案包括调整Log4j2配置

本文分享了10个Redis在Java项目中的实用场景：1）限流防崩，2）分布式锁防重复订单，3）延时任务处理超时订单，4）实时热点数据统计，5）异步消息队列，6）全局唯一ID生成，7）用户在线状态管理，8）防重提交，9）会话存储，10）秒杀库存预减。这些方案能有效应对高并发、数据一致性等问题，提升系统性能和用户体验。Redis适合数据量不大但访问频繁的场景，对于大数据量仍需专业解决方案。

Redis分布式锁实现原理：通过Hash结构存储锁名、线程标识和重入次数，Lua脚本保证原子性操作。加锁时自动续期（看门狗机制），解锁时递减计数并通知等待线程。支持可重入和公平锁（ZSET排队）。核心特性包括原子性操作、自动续期和线程安全，确保分布式环境下锁的可靠性和高效性。

本文分享了作者使用AICoding工具（特别是ClaudeCode）提升开发效率的经验。重点包括：1）Prompt工程技巧，强调清晰的需求描述和结构化表达；2）合理划分AI任务边界，建议仅将明确需求且能力范围内的任务交给AI；3）小步快跑开发策略，强调代码可验证性和模块化；4）AI代码必须人工Review，建议防御性编程；5）有效管理上下文的方法，包括信息压缩和外部记忆辅助；6）ClaudeCode使用经验，介绍了其原理、安装、工作流程和多实例协同技巧。作者还展示了ClaudeCode在旅游规划、PPT制作

MySQL死锁问题解析与优化方案 摘要：本文深入分析了MySQL死锁问题，从事务隔离机制、锁类型与粒度入手，揭示了死锁成因（顺序不一致、间隙锁冲突等）。针对高频死锁场景提供了五维防御策略：索引优化、事务设计、批量操作优化等，并结合典型案例提出解决方案。文章指出理解事务ACID特性、MVCC机制及InnoDB锁原理（记录锁/间隙锁/临键锁）是预防死锁的关键，建议通过规范加锁顺序、控制事务粒度、合理设置隔离级别等措施，结合SHOW ENGINE INNODB STATUS等工具进行监控优化。（149字）

本文探讨了分布式ID生成方案，对比分析了MySQL自增ID和UUID作为主键的优劣，指出自增ID顺序写入性能高但依赖数据库，UUID随机写入效率低。重点介绍了基于Snowflake算法的改进方案：美团Leaf通过Zookeeper分配workerId并解决时钟回拨问题；百度UidGenerator采用原子自增时间戳和预生成缓存环提升性能。文章最后总结了各方案特点，为高并发场景下的分布式ID生成提供了技术参考。

本文介绍了基于云原生架构的用户标签系统设计与实现。该系统通过整合用户静态和动态数据，构建精准的用户画像，支持企业精细化运营与智能决策。文章详细阐述了标签系统的核心功能模块（标签定义、计算引擎、模型管理、交互式服务等）和分层架构设计（数据采集、存储、计算、应用层）。关键技术包括：1）基于ANTLR的标签公式解析；2）Spark大规模离线计算与Elasticsearch实时计算结合；3）多层级树形模型评分；4）多存储系统数据同步。该系统采用微服务架构，具有高扩展性和灵活性，为企业构建用户画像平台提供了完整解决方

本文深入探讨了缓存技术的核心原理与应用实践。从缓存基础概念到多级架构设计，详细解析了命中率、回收策略等关键指标，对比了Guava、Ehcache等主流框架特性。通过Cache-Aside、Read-Through等典型模式分析，结合NULL缓存、双删策略等高级技巧，提供了完整的缓存解决方案。文章还针对穿透、击穿、雪崩三大问题给出防护措施，并探讨了堆外缓存等性能优化方案，为构建高性能系统提供了实用指南。最后强调需根据业务场景选择合适策略，实现缓存效果最大化。

Kafka凭借分布式架构和极致优化实现亿级并发：1）分区化设计实现并行读写，集群动态扩容；2）顺序I/O+零拷贝技术突破磁盘瓶颈，吞吐接近内存速度；3）批处理与压缩提升有效传输效率；4）副本机制保障高可用。核心通过分区并行、高效I/O、批处理压缩三大技术协同，配合合理配置与硬件资源（SSD/大内存/高速网络），实现超高性能。其设计精髓在于将分布式架构优势与单机性能压榨完美结合。

举个例子，我入职的第一个月，就经历了一次比较严重的线上故障：当时另一个业务组突然上线了一个新功能，里面包含了大量的Redis大Key操作，导致我们共享的Redis集群响应变得非常慢，最终拖垮了我们的核心服务，造成了长时间的业务中断。最佳的面试策略，就是在自我介绍时就主动抛出引子，例如提到自己在“高可用微服务架构”方面的丰富经验，然后在介绍项目时，着重展示你在入职后，是如何大幅度提高了系统的可用性。当然，这里给出的整个话术和方案，是一个“框架”，面试的时候你需要根据你的实际项目经验，来填充血肉。

决策维度说明推荐实践任务紧迫度是否允许任务被延迟执行紧迫性任务建议使用专属线程池，非紧迫任务可使用共享线程池- 紧迫性任务对响应时间敏感，必须尽快执行如接口响应、同步业务主流程- 非紧迫性任务对时效要求不高，只需最终完成如日志上报、异步通知结果敏感度是否需要获取任务执行结果区分（敏感）与execute（不敏感）- 结果敏感性任务提交后需获取结果，结果影响主流程需精细化控制线程资源，防止结果超时- 结果不敏感任务只需执行，不关心结果可交由复用线程池或后台异步处理。

摘要：本文探讨了高并发场景下多级缓存架构的解决方案。以咖啡新品发布为例，分析了传统架构面临的瞬时高并发、热点数据集中和缓存失效风暴等痛点，提出本地缓存+Redis的多级缓存体系。详细介绍了Caffeine本地缓存配置、Redis集群优化、缓存穿透/击穿/雪崩防护策略，以及监控降级方案。实施效果显示，该架构将数据库请求削减99%以上，响应时间从秒级降至毫秒级，系统吞吐提升显著。关键成功要素包括精细缓存策略、充分预热和全面监控，未来可向智能预测、边缘计算等方向演进。

摘要：某电商平台在大促期间因网关限流导致订单服务异常，虽然CPU和内存使用率正常，但接口响应时间骤增。排查步骤包括：1）检查线程栈状态，识别阻塞/等待线程；2）分析依赖服务性能（数据库慢查询、下游RT）；3）监控JVM垃圾回收情况；4）诊断网络与连接池问题；5）分析日志链中的超时和重试记录。常见根因包括数据库锁竞争、连接池耗尽或GC频繁。建议采用线程池隔离、降级策略和全链路压测预防类似问题。

摘要：CPU飙升100%是Java应用中常见问题，可通过jstack和arthas工具快速定位。解决步骤：1）使用top命令找到高CPU进程；2）用jstack获取线程堆栈，将线程ID转换为16进制后匹配定位问题代码；3）分析RUNNABLE状态的线程调用栈，常见死循环、锁竞争等问题。arthas提供dashboard和thread命令简化排查。案例表明，死循环问题通常显示固定代码位置，锁竞争则呈现多线程BLOCKED状态。建议保存堆栈快照优先于重启，并建立监控预警机制。该方法能在15分钟内解决90%的CP

SQL语句中锁的使用与优化

摘要：Java后端开发中，单人维护代码量和月提交行数因经验级别而异：初级工程师（1-5年）维护5-15万行，月提交2000-3000行；高级（5-10年）维护20-50万行，提交1500-2500行；资深（10年+）维护50万+行，提交500-1500行，常通过删除冗余代码实现负增长。关键影响因素包括代码质量、项目阶段和团队规范。行业趋势强调避免唯行数论，建议采用删除冗余、统一规范、自动化工具等提升维护效率。核心原则是代码价值在于解决实际问题的效率而非数量。

幂等性处理：重试仅适用于GET/PUT等幂等操作，非幂等操作(POST)需谨慎重试策略基础场景：RestTemplate +@Retryable微服务间调用：OpenFeign + 自定义Retryer生产环境：Resilience4j + 熔断降级关键参数最大重试次数：通常3-5次退避策略：指数退避（如：首次500ms，第二次1000ms）超时设置：比重试间隔短监控：集成Micrometer + Prometheus监控重试指标异常处理。

在需要精确的小数计算时再使用BigDecimal，BigDecimal的性能比double和float差，在处理庞大，复杂的运算时尤为明显。故一般精度的计算没必要使用BigDecimal。尽量使用参数类型为String的构造函数。BigDecimal都是不可变的（immutable）的， 在进行每一次四则运算时，都会产生一个新的对象 ，所以在做加减乘除运算时要记得要保存操作后的值。构造方式优先使用String构造或比较操作始终使用而非equals()除法运算必须指定精度和舍入模式（精度控制。

Java 中实现 Excel 导入一些疑难杂症，Excel导入导出字段无法映射问题相关

在当今微服务架构盛行的时代，分布式系统已经成为企业级应用的标准模式。然而，随之而来的分布式事务问题也成为了开发人员的一大挑战。在复杂的供应链系统中，各个业务模块之间的数据一致性一直是一个重要且棘手的问题。物流、库存、订单等系统相互协作，如何在保证业务高效运转的同时，确保跨系统操作的数据一致性？今天，我们将深入探讨一个专为解决供应链分布式事务问题而设计的框架——「一致性框架」。二在分布式系统中，一致性框架是确保系统可靠性的重要工具。

代码层面避免大事务，拆分业务逻辑设置合理的事务超时移除事务中的远程调用配置层面优化连接池参数设置合理的连接泄露检测运维层面建立实时监控告警定期进行压力测试实施事务治理策略架构层面引入熔断降级机制采用异步处理模式实现最终一致性方案通过以上综合措施，可有效预防和解决大事务导致的数据库连接池耗尽问题，保障系统稳定运行。