<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Java_Chuck的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Java_Chuck</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Java_Chuck]]></copyright><item><title><![CDATA[Java栈OOM精准定位实战指南]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263402</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263402</guid><author>Java_Chuck</author><pubDate>Sat, 18 Apr 2026 04:58:03 +0800</pubDate><description><![CDATA[预防与基线合理设置-Xss参数，在压测中验证。在监控平台建立JVM线程数的基线，并设置智能告警。代码审查时警惕深度递归和线程池的滥用。事发时应急第一时间保存应用日志和jstack线程转储。检查监控图表，确认线程数是否出现尖刺或持续增长。如果应用在容器中，检查容器和节点的内存使用情况。事后深度分析使用文本分析工具（如grepawk）或在线分析网站分析jstack文件，定位问题线程和调用栈。]]></description><category></category></item><item><title><![CDATA[Java heap space OOM 精准定位与体系化排查方案]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263206</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263206</guid><author>Java_Chuck</author><pubDate>Sat, 18 Apr 2026 04:51:43 +0800</pubDate><description><![CDATA[可视化工具将二进制的堆快照转化为直观的图表和引用关系图，让开发者能够。]]></description><category></category></item><item><title><![CDATA[精准定位Direct Buffer OOM的体系化排查实践]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263093</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160263093</guid><author>Java_Chuck</author><pubDate>Sat, 18 Apr 2026 04:41:33 +0800</pubDate><description><![CDATA[针对这类堆外内存泄漏问题，其隐蔽性高于堆内泄漏，排查必须遵循从宏观监控到微观代码的体系化路径。以下是结合生产实践的完整排查方案。生产环境的集中监控是发现问题的第一道防线，它能提供泄漏的，通常无法直接定位根因。通过JMX Exporter或Micrometer暴露JVM的监控仪表盘只能回答，例如“直接内存使用率在03:00后持续攀升”。但它无法回答，即无法告诉你是哪段代码、哪个对象持有了这些未被释放的。因此，监控告警是。当监控告警后，需要登录问题实例进行深度诊断。仅依赖参数是远远不够的。]]></description><category></category></item><item><title><![CDATA[JVM内存模型与垃圾回收全解析]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160262999</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160262999</guid><author>Java_Chuck</author><pubDate>Sat, 18 Apr 2026 04:13:40 +0800</pubDate><description><![CDATA[这是JVM在运行Java程序时，对物理内存的逻辑划分，是。JMM是一个，定义了Java程序中共享变量的访问规则，旨在解决多线程环境下的问题。它规定了线程如何与主内存及工作内存进行交互。lockunlockreadloaduseassignstorewritevolatilei++finalfinal这是判断对象是否存活的。以一系列“GC Roots”对象为起点，向下搜索，形成引用链。任何到GC Roots的对象，即为不可达，可被回收。这是。]]></description><category></category></item><item><title><![CDATA[Kafka:  一条消息的完整“生命之旅”]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160238348</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160238348</guid><author>Java_Chuck</author><pubDate>Sat, 18 Apr 2026 03:22:05 +0800</pubDate><description><![CDATA[graph LR A[生产者] -->|1. 发送消息| B[指定主题的某个分区] B --> C[分区领导者副本] C -->|2. 复制| D[分区跟随者副本] D --> E[已提交的消息] E -->|3. 拉取消息| F[消费者组] F --> G[消费者实例]对于之前混淆的错误，再次深表歉意。：Kafka服务实例，一个Kafka集群由多个Broker组成，负责消息的存储和传递。：消息的逻辑分类，你可以把它想象成一个数据库的表名或一个消息队列的名称。：数据的终点，负责从Kafka拉取并处理消息。]]></description><category></category></item><item><title><![CDATA[线上告警！Kafka积压百万消息，我们是这样快速止血的]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160237762</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160237762</guid><author>Java_Chuck</author><pubDate>Fri, 17 Apr 2026 09:48:00 +0800</pubDate><description><![CDATA[通过编写代码将积压消息转发到高分区新主题，并配套弹性临时消费者的方案，是一种经典的“空间换时间”和“解耦”的应急处理模式。它通过架构上的隔离与资源的弹性投入，能够快速形成对海量积压消息的“消化能力”，为后续根因排查和系统修复赢得宝贵时间窗口，是处理Kafka百万级消息积压中最主流且有效的技术手段之一。]]></description><category></category></item><item><title><![CDATA[Kafka消息不丢失全攻略]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160236677</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160236677</guid><author>Java_Chuck</author><pubDate>Fri, 17 Apr 2026 09:33:17 +0800</pubDate><description><![CDATA[环节核心目标关键配置/动作说明与影响生产者确保消息成功送达Broker并持久化acks=all最高可靠性保证，等待所有ISR副本确认。防止网络重试导致重复开启幂等生产者，实现精确一次语义。应对临时故障retries设为较大值配合，自动重试可恢复的失败。可靠发送方式使用异步发送并监听回调，处理异常。Broker数据冗余，防止单点故障多副本机制是数据高可用的基础。定义持久化成功的标准与acks=all配合，确保写入足够多的副本。消费者避免消息未处理就被认为已消费必须关闭，采用手动提交。]]></description><category></category></item><item><title><![CDATA[分布式事务: 主流最终一致性方案对比]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160236035</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160236035</guid><author>Java_Chuck</author><pubDate>Fri, 17 Apr 2026 09:25:59 +0800</pubDate><description><![CDATA[分布式事务的最终一致性方案旨在确保在分布式系统中，所有参与方最终将达到一致的状态，尽管在过程中可能存在短暂的不一致。这种模型在保证系统可用性和分区容错性的同时，牺牲了强一致性的实时性要求。以下是几种主流的最终一致性方案的汇总与详解。]]></description><category></category></item><item><title><![CDATA[分布式事务最佳实践:基于kafka实现的最终一致性方案]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160235164</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160235164</guid><author>Java_Chuck</author><pubDate>Fri, 17 Apr 2026 09:18:52 +0800</pubDate><description><![CDATA[在真实实践中，为了提升消息实时性，在业务与消息事务提交后立即触发MQ投递是一种有效的优化模式。其最佳实践是结合与@Async，它既保证了触发时机与事务成功提交的严格绑定，又通过异步执行避免了对主流程的性能影响。然而，这种模式并未改变最终一致性的本质，只是缩短了不一致状态的时间窗口。必须通过生产者重试、消费者幂等、兜底定时任务补偿以及完善的监控告警这一整套“组合拳”，来应对网络不可靠、服务抖动等分布式环境中的固有挑战，从而在享受低延迟好处的同时，确保系统的最终数据一致性。]]></description><category></category></item><item><title><![CDATA[Redis高频面试题核心机制深度解析：速度之源、内存淘汰与持久化实战]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160206023</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160206023</guid><author>Java_Chuck</author><pubDate>Fri, 17 Apr 2026 08:53:13 +0800</pubDate><description><![CDATA[Redis之所以能在十几年间保持其领先地位，不仅因为其极致的性能，更因为其不断演进的设计哲学。从单线程到多线程I/O，从简单的LRU到智能的LFU，从RDB/AOF二选一到混合持久化，每一次演进都体现了工程上的务实与智慧。在实际应用中，没有"最好"的配置，只有"最适合"的配置。理解业务的数据访问模式，监控系统的实际表现，才能做出最合理的技术选择。希望本文能帮助你在Redis的深度使用上更进一步，构建出更稳定、高效的系统。参考资料《Redis设计与实现》]]></description><category></category></item><item><title><![CDATA[Redis集群高频面试题全解析：从入门到精通，一篇文章搞定！]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160203680</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160203680</guid><author>Java_Chuck</author><pubDate>Thu, 16 Apr 2026 10:13:33 +0800</pubDate><description><![CDATA[Redis槽（Slot），通常称为哈希槽，是Redis集群实现数据分片（Sharding）的核心机制。简单来说，它就像一个大仓库的16384个编号货架，每个货架都有固定的管理员（Redis节点）。逐步提问Q1：槽的数量是固定的吗？A：是的，固定16384个（0-16383）Q2：为什么是16384，不是10000或20000？网络通信效率：集群节点间需要同步槽分配信息16384个槽用2KB内存就能存储（16384/8=2048字节）如果65536个槽，需要8KB，网络传输和内存占用都翻4倍。]]></description><category></category></item><item><title><![CDATA[Redis分布式锁：从Setnx到RedLock的深度解析]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159891</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159891</guid><author>Java_Chuck</author><pubDate>Thu, 16 Apr 2026 10:01:23 +0800</pubDate><description><![CDATA[Redis分布式锁是一个强大但需要谨慎使用的工具。从简单的SETNX到复杂的RedLock，每种方案都有其适用场景和局限性。在实际应用中，需要根据具体的业务需求、性能要求和可靠性要求来选择合适的实现方案。基础实现：优先使用SET命令的NX参数，避免SETNX的竞态条件锁安全：使用唯一值防止误释放，Lua脚本保证原子性高级特性：Redisson提供了可重入锁、读写锁等高级特性可靠性：对于关键业务，考虑使用RedLock或基于共识算法的锁监控与降级：完善的监控体系和降级策略是生产环境的必备。]]></description><category></category></item><item><title><![CDATA[一文讲透mysql的索引树:从图书馆的故事开始]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160202508</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160202508</guid><author>Java_Chuck</author><pubDate>Thu, 16 Apr 2026 09:59:03 +0800</pubDate><description><![CDATA[当“总目录页30”的格子也写满时，总目录自己也会分裂，产生更高一级的“超级总目录”，树就从2层长高到3层。要找第1000万本书，你需要从顶层开始，做出大约24次（log₂(1000万)）选择，也就是访问24个分散在不同位置的“决策点”。你要找一本编号为“9527”的书，唯一的办法就是从第一本开始，一本一本地翻看编号，直到找到为止。要找第1000万本书，你只需要做3-4次选择（访问3-4个页），就能定位到书架。16KB的大小，能让内存同时缓存足够多的页，同时每页携带的数据量也足够有用。这是最容易误解的地方。]]></description><category></category></item><item><title><![CDATA[永不忘算法：三数之和的“双指针”魔法]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160091895</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160091895</guid><author>Java_Chuck</author><pubDate>Wed, 15 Apr 2026 09:06:35 +0800</pubDate><description><![CDATA[排序：这是双指针法的前提，没有排序就没有方向感。定一移二：先定住第一个数，剩下的用两个指针从两头往中间凑。去重：选队长时看前一个，移动指针时看下一个，只要数字一样就跳过。这就是“三数之和”的奥秘。你学会了吗？]]></description><category></category></item><item><title><![CDATA[一条SQL执行过程：从查询到结果的奇幻之旅]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159568</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159568</guid><author>Java_Chuck</author><pubDate>Wed, 15 Apr 2026 01:46:24 +0800</pubDate><description><![CDATA[这个顺序永远不会改变，就像做菜必须先备料再烹饪一样。]]></description><category></category></item><item><title><![CDATA[MySQL事务隔离级别实现原理：用生活例子讲透，小白3分钟看懂]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159495</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160159495</guid><author>Java_Chuck</author><pubDate>Wed, 15 Apr 2026 01:31:09 +0800</pubDate><description><![CDATA[我们开一家「小明奶茶店」，用一张orders现在有两位店员（事务A和事务B）同时工作——这就是并发。]]></description><category></category></item><item><title><![CDATA[Hermes 搭建 Karpathy LLM Wiki：进阶版]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160154416</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160154416</guid><author>Java_Chuck</author><pubDate>Tue, 14 Apr 2026 19:07:05 +0800</pubDate><description><![CDATA[通过 Hermes 搭建 Karpathy 风格的 LLM Wiki，本质上是在构建一个具备自我演化能力的智能知识体。放弃对实时检索的过度依赖，利用 LLM 的理解能力在写入阶段完成知识固化。Schema 驱动，用规则约束保证结构化质量。充分利用 Agent 机制，借助 Hermes 的 Skill 沉淀与双层记忆，实现知识的长期复利。这不仅仅是一个文档库，更是你第二大脑的操作系统。]]></description><category></category></item><item><title><![CDATA[Hermes 搭建 Karpathy LLM Wiki：抛弃 RAG 检索，用“编译”思维打造智能知识库]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/160091884</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/160091884</guid><author>Java_Chuck</author><pubDate>Mon, 13 Apr 2026 03:47:49 +0800</pubDate><description><![CDATA[用 Hermes 搭建 Karpathy LLM Wiki，就像是请了一位 24 小时的 AI 知识管家。它把复杂的代码、向量检索和上下文拼接都封装在了llm-wiki技能里。把文件丢进raw文件夹。告诉 Hermes “开始处理” 和 “做个体检”。快来体验这种抛弃传统 RAG、拥有“外挂大脑”的感觉吧！]]></description><category></category></item><item><title><![CDATA[SpringCloudGateway&SpringBoot开启accesslog]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/123211958</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/123211958</guid><author>Java_Chuck</author><pubDate>Tue, 01 Mar 2022 18:08:35 +0800</pubDate><description><![CDATA[SpringCloudGateway&SpringBoot开启accesslog]]></description><category></category></item><item><title><![CDATA[记一次接口授权导致的500异常排查]]></title><link>https://blog.youkuaiyun.com/Java_Chuck/article/details/117223070</link><guid>https://blog.youkuaiyun.com/Java_Chuck/article/details/117223070</guid><author>Java_Chuck</author><pubDate>Mon, 24 May 2021 18:04:52 +0800</pubDate><description><![CDATA[有一个导出的接口通过postman调用是返回正常的响应体，但是发布到测试环境，通过浏览器请求时，会返回500

通过浏览器请求





通过Postman请求



开始排查

整个链路为nginx -&gt; spring cloud gateway -&gt; 业务服务

首先从业务服务开始排查，增加一个log过滤器，打印下请求响应信息


2021-05-24 14:43:00.447 aom-platform-[,] [http-nio-9991-exec-9] ERROR o.a.c.c.C.[]]></description><category></category></item></channel></rss>