文章内容收录到个人网站，方便阅读：http://hardyfish.top/JDK 7（以及之前）默认垃圾回收器： 新生代：Parallel Scavenge（吞吐量优先收集器）老年代：Parallel Old特点： 并行 GC：多线程回收新生代和老年代，适合批处理、后台任务等吞吐量优先场景。STW（Stop-The-World）时间相对较长。调优主要依赖 -XX:MaxGCPauseMillis 和 -XX:GCTimeRatio。JDK 8默认垃圾回收器：Parallel GC（新生代 Parallel Scavenge + 老年代 Parallel Old）。特点： 吞吐量优先。新生代复...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/这是一个典型的“消息分发模型”设计问题，微博/社交平台在设计大V发博分发时，推模式（push） 和 拉模式（pull） 各有利弊。下面结合你提到的“大V发博客”场景详细分析：一、两种模式简介推模式（push）大V一发微博，系统立即将内容推送到每一个粉丝的时间线中（如写入粉丝的消息队列或Feed中）拉模式（pull）粉丝查看时间线时，实时去拉取他关注的人（如大V）最新发布的内容，再合并排序显示二、微博类应用场景选型✅ 小V/普通用户：使用 推模式粉丝数少，推送量小；内容分发量级低；直接推送到粉丝的 Feed 表中，读取快...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/跳表（SkipList）是 一种有序链表的多级索引结构，通过增加多层索引来加快查找速度。最底层：完整的有序链表（包含所有元素）。上层索引：抽取部分节点作为快捷通道，减少查找步数。查找过程：从最高层索引开始，能向右就向右，不能向右就向下，直到找到目标或最接近的位置。举例（每层越上节点越少）： Level 3: 1 --------- 9 Level 2: 1 --- 5 --- 9 Level 1: 1 3 5 7 9 找元素 7 的过程：从 Level 3 的 1 → 9（超了，往下）Level 2 的 1 → 5 →...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/阿里巴巴 Java 开发手册中明确推荐：使用 ThreadLocal 时必须使用 static 修饰。原因如下。避免内存泄漏的风险原理：每个 Thread 都持有一个 ThreadLocalMap，而这个 Map 的 key 是 ThreadLocal 的弱引用。如果你创建的 ThreadLocal 是非 static 成员变量，它会跟随外部类实例的生命周期。一旦外部类被 GC 回收，而 ThreadLocal 实例也没强引用，就会造成：ThreadLocal 被 GC。ThreadLocalMap 中 key 为 n...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/JVM 年轻代（Young Generation）回收频率过高 可能导致 应用性能下降、GC 开销过大，进而影响系统吞吐量。要找出 导致高频 GC 的具体原因，一般需要按照以下步骤进行分析和优化。现象分析年轻代 GC 过于频繁的常见表现：应用吞吐量下降，CPU 使用率升高Full GC 次数增加，可能因为晋升失败Young GC 频繁触发，应用线程被频繁打断监控 JVM GC 情况通过 JVM 选项打开 GC 日志可以通过 GC 日志 观察 GC 频率： # JDK 8 -XX:+PrintGCDetails -XX:...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/ZAB（Zookeeper Atomic Broadcast）是 ZooKeeper 专门设计的一种原子广播协议，用于保证 数据一致性 和 故障恢复。它主要用于 主从复制（Leader-Follower） ，并确保 写请求（事务）严格有序，同时保证集群在发生 Leader 失效 时能正确恢复。1. ZAB 协议核心目标保证数据一致性 ZooKeeper 采用 强一致性（Linearizability） ，所有写入（事务）按顺序执行。支持主从复制 通过 Leader 负责写操作，Follower 只进行读操作，确保数据同...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/提到“虚拟线程”，很多人可能会觉得陌生，但如果你了解过像Go、Ruby或Python这样的语言，可能马上会联想到“协程”。没错，JDK 21引入的虚拟线程（Virtual Thread），本质上就是Java版的协程，旨在解决传统线程模型的性能瓶颈。传统Java线程的问题在JDK 21之前，Java的线程模型比较简单，采用的是“一对一”的映射方式：每个Java线程对应操作系统的一个轻量级进程（通常是内核线程）。这种模型下，线程的创建、销毁和同步操作都需要系统调用，而系统调用需要在用户态和内核态之间切换，开销不小。尤其是在...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/Kafka 只能保证分区内的顺序写、顺序读，跨分区不保证全局顺序。写入顺序（Producer → Broker）一个 Partition 内，日志是顺序追加，消息写入顺序 = Offset 顺序。想要应用侧严格不乱序（尤其发生重试时），建议：同一键路由到同一分区：给 key，让相同 key 的数据被同一分区顺序写。开启幂等：enable.idempotence=true（Kafka ≥0.11），避免重试导致乱序/重复。版本较老或要求最稳妥：max.in.flight.requests.per.connection=1...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/普通LRU算法LRU = Least Recently Used（最近最少使用）：也就是末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰数据。当要访问某个页时，如果不在Buffer Pool中，需要把该页加载到缓冲池。并且把该缓冲页对应的控制块作为节点添加到LRU链表的头部。当要访问某个页时，如果在Buffer Pool中，则直接把该页对应的控制块移动到LRU链表的头部。当需要释放空间时，直接从末尾淘汰。普通LRU算法的优缺点优点：所有最近使用的数据都在链表表头，最近未使用的数据都在链表表尾，保证热数据能最快被获...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/ThreadLocal 本身设计上是为了解决线程之间共享变量带来的并发问题，但使用不当时，确实可能导致内存泄露甚至最终导致 OutOfMemoryError（OOM） 。下面是具体可能导致 OOM 的几种情况：一、根本原因：ThreadLocalMap 的 Entry 是弱引用，但 value 是强引用在 ThreadLocal 的底层实现中，每个线程 (Thread) 都维护一个 ThreadLocalMap，其 key 是 ThreadLocal 对象的 弱引用，value 是实际存储的对象，强引用。弱引用的影响：...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/ZGC，全称为Z Garbage Collector，是Java 11开始引入的一种低延迟、高吞吐的垃圾收集器，特点是：停顿极短：停顿时间通常在10ms以下，甚至达到亚毫秒级别。并发设计：几乎所有GC操作（标记、清理、压缩）都能与应用程序并发进行，大幅减少了应用暂停时间。支持超大堆内存：最高支持TB级别的堆内存，尤其适合内存较大的应用场景。ZGC 核心特点：Region-based 内存布局： 将堆分割成动态大小的Region，以便实现精细的内存管理。Region大小从几MB到数百MB不等，便于高效回收。并发标记、转移...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/Redisson 支持公平锁，实现类为： RLock lock = redisson.getFairLock("myLock"); 一、什么是公平锁？公平锁表示： 多个线程在获取锁时，按照请求锁的先后顺序来获取锁，先申请锁的线程，先获得锁。二、Redisson 公平锁的实现原理：Redisson 的公平锁（Fair Lock）底层是基于 Redis数据结构（ZSet + List） 实现的，和普通锁（RLock）实现有差异：Redisson 公平锁会用两个关键的 Redis 数据结构：List：队列...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/RocketMQ顺序消息（Ordered Message）保证消息严格按照顺序消费，但顺序消费天然会限制消息吞吐量。如果需要提高吞吐量，可以从以下几个维度进行优化：一、增加队列数（合理划分队列粒度）顺序消息在RocketMQ中是基于单个Queue顺序消费的，队列越多，并发消费能力就越强。实践： 将消息按照顺序要求的业务主键进行分片（如订单号、用户ID），同一个分片的消息投递到同一个队列中，不同分片的消息可以并行消费，从而提高整体吞吐量。例如： // 根据订单号取模，确定投递的队列 int queueNum = orde...

文章内容收录到个人网站，方便阅读：http://hardyfish.top/数据库加密可以保护数据安全，但同时也会导致模糊查询变得困难。因为加密后的密文和原始明文之间没有直接对应关系，无法使用 LIKE 或 REGEXP 进行模糊匹配。例如， "Alice" 加密后可能变成 "8F2D5A6B9C..." ，而 "Ali" 加密后可能变成 "3B7E91F4D8..." ，两者完全不同，无法匹配。1. 先解密再查询（不推荐）思路：查询时先解密字段，然后在应用层或 SQL 中进行模糊匹配。 SELECT * FROM...