洛豳枭薰

原创 Kafka rebalance机制

理解 Rebalance，不仅要知道**“怎么分”（分配策略：Range/RoundRobin/Sticky/Cooperative），更要知道“谁来分”（Coordinator 统筹，Leader 计算），以及“怎么交互”**（JoinGroup -> SyncGroup）。其他普通的 Consumer 收到的响应是空的。Kafka 将分配的权利下放给了客户端。Coordinator 收到 Leader 的分配方案后，将对应的分配结果作为 SyncGroup 的响应，分别下发给每一个 Consumer。

原创 Kafka 事务机制

| ||--- 1. 发送业务数据 ----->| || |--- 2. 写入真实数据 --------->| (数据不可见)| | ||=== 开始两阶段提交 =======| || | ||--- 3. 请求 Commit ------>| || | || |-- 4. 写 PREPARE_COMMIT 到记事本 (不可逆点!| | || |-- 5. 发送 Commit Marker ---->| (数据对消费者可见!| | |

原创 Kafka概述

Kafka 的设计哲学在于**“做减法”**——它将复杂的消息状态管理交给消费者（通过维护 Offset），将数据缓存交给操作系统（Page Cache），采用最简单的追加写（Append-only Log）实现存储，从而在架构上保证了极致的吞吐量和极高的稳定性。每个 Partition 都有多个副本。它的设计非常精妙，将传统的消息队列与日志存储系统的优势结合在了一起。每个 Partition 在物理上对应一个文件夹，数据以追加写（Append）的方式写入日志文件，保证了极高的写入速度（顺序写磁盘）。

原创 kafka Epoch机制

当 Follower 重启恢复时，它不再盲目根据 HW 截断日志，而是向当前的 Leader 发送一个 OffsetsForLeaderEpoch 请求，询问：“在我的 Epoch 时代，最新的有效 Offset 是多少？当前状态：有一条消息（Offset=1）已经写入 A 和 B，此时 A 的 LEO=2，B 的 LEO=2。B 发现自己的 LEO 也是 2，并没有超过 Leader 的有效范围，因此 B 保留了 Offset=1 的消息，不做任何截断。A 的 HW=2，B 的 HW=1。

原创 Kafka zookeeper和KRaft架构

它不仅让 Kafka 变成了一个轻量级、单一依赖的系统（简化了部署）2，更重要的是，通过将“元数据管理”转化为 Kafka 最擅长的“事件日志处理”模式，彻底解放了 Kafka 的性能和扩展性潜力 59。元数据即日志（Event Store）：在 KRaft 模式下，集群的元数据（如节点状态、Topic 配置）不再存放在外部，而是被当作普通的 Kafka 消息，存储在一个内部的 Metadata Topic（事件源日志主题）中 510。Leader（领导者 / 班长）： 集群中唯一的“霸道总裁”。

原创 如何实现缓存预热

如果是跨Bean、跨组件的业务级数据加载（比如查数据库放进Redis），首选实现 ApplicationRunner 接口，并建议在里面开启新线程（@Async）去慢慢加载，让主流程赶紧走到 ApplicationReadyEvent 去开门迎客！如果此时用户发起请求，请求会进入 Controller，但由于缓存还没预热完，可能会导致请求查不到数据，或者大量请求直接击穿到数据库。(此时Spring容器已经完全初始化，Tomcat也起来了，所以在这里做缓存预热非常安全，不会影响Bean的创建过程)。

原创 ThreadLocal

原因：正如前面深入探讨过的，ThreadLocalMap 的 Key 是弱引用（GC 自动回收），但 Value 是强引用。因为这门课再也不上了，贴在小明书包夹层上的**【临时科目-1】标签失去了存在的意义，自动脱落了**（这就是 ThreadLocal 作为弱引用的特性：外部没用了，GC 就会把 Key 回收掉，Key 变成了 null）。小明（线程）很听话，他在书包里找了一个空的夹层，在外面贴上**【临时科目-1】的标签（Key）**，然后把 40斤的大石头（Value） 塞进了这个夹层里。

原创 为什么MySQL用B+数，mongDB用B数，redis用跳表？

更低的磁盘 I/O 次数：由于 B+ 树的非叶子节点不存放 Data，只存放 Key，这使得每个节点能容纳更多的索引项（高扇出）。首先必须澄清一个重要事实：现代 MongoDB（3.2+ 版本）的默认存储引擎是 WiredTiger，而 WiredTiger 使用的是 B+ 树（B+Tree）的变种，而非传统 B 树！核心原因并非“B 树比 B+ 树快”，而是 MongoDB 的存储引擎、数据模型、查询模式与 MySQL 存在根本性差异，导致 B 树（或其变种）在特定维度上更具综合优势。

原创 Window-TinyLFU

技能：用极小的内存（Count-Min Sketch 技术），记住了所有数据（哪怕不在缓存里）的历史访问频率。结果：50 > 10。《某老片》被淘汰，《狂飙》进入 试用区 (Probation)。第一阶段：《狂飙》进门房 -> 被挤出 -> PK 失败（因为刚发布，频率低） -> 被扔掉。动作：VIP 区里最久没被看的那位老大哥（比如《老友记》），被降级回到 试用区。规则：如果在这里没人理你（没被再次访问），你就是下一个被淘汰的候选人。第三阶段：《狂飙》再次被加载进门房 -> 被挤出 -> 再次 PK。

原创 (BitMap & BitSet)10位QQ号，40亿个QQ号，只有1G内存，怎么去重

如果面试官强调 QQ 号可能达到 99 亿（超过 unsigned int 范围），导致 1.25 GB 的位图无法一次性装入 1 GB 内存，可以采用 分块处理（分治法）。在内存中申请一块大小为 512MB 的内存空间（即创建一个 byte 数组或 int 数组），并将所有位初始化为 0。如果数据值 ≥50亿，将其减去 50亿（映射到 0~50亿 的下标），在位图中操作。M 是数据样本个数（40亿），因为每次查找和赋值都是 O(1) 的。空间复杂度：O(N/8)，其中 N 是数值的最大范围。

原创 Redis 基础数据结构

内层（编码层）： Redis 根据数据量大小和类型，自动切换的底层实现（如 Listpack, QuickList, HashTable, SkipList），以在“省内存”和“高性能”之间寻找平衡。Hash/ZSet 变身： 小时候是 Listpack（省内存），长大了变 HashTable/SkipList（拼速度）。外层（对象层）： 开发者使用的 5 大基础类型（String, List, Hash, Set, ZSet）。对比红黑树： 实现更简单，范围查询更高效（直接遍历链表），内存更省。

原创 分布式事务进阶

我们将系统拆分成了：订单服务（Order DB）、库存服务（Stock DB）、账户服务（Account DB）。结论：我们需要一种机制，能跨越网络，保证这三个操作要么一起成功，要么一起失败。原理：依赖数据库的 Connection，开启事务 -> 执行 SQL -> 提交/回滚。结论：本地事务（Local Transaction） 是完美的。如果 1 和 2 成功了，3 失败了（余额没扣），怎么办？ACID：数据库（DB）帮你搞定了一切。原子性（A）：要么全成功，要么全失败。2. 现在的世界（微服务）

原创 线上 Full GC 故障模拟

该代码会持续填充堆内存至 80% 以上，并反复震荡，迫使 G1 收集器陷入“清理-失败-清理”的死循环。-Xloggc:gc.log: 怎么跑？现象：找到 java 进程（记下 PID，例如 8060），观察 %CPU 是否接近或超过 100%。FGC (Full GC Count): 数字在不断增加 (561 -> 562 -> 563)。FGCT (Full GC Time): 时间增长迅速，说明 CPU 都在做 GC。故障现象：CPU 飙高，应用响应卡顿，GC 日志疯狂刷屏，但进程未崩溃（假死）。

原创 G1垃圾回收器执行流程

G1 会连续发起多次 Mixed GC（默认最多 8 次），每次回收一部分老年代，直到回收得差不多了，或者时间不够了，才会结束 Mixed GC 周期，回到纯 Young GC 模式。并发标记之所以难，是因为GC 线程在标记垃圾的时候，你的业务线程（应用线程）还在修改对象之间的引用关系。G1 使用SATB算法，在并发标记开始时“拍个快照”，在标记过程中，凡是引用关系发生变化导致原本存在的对象引用消失，G1 都会把这些对象记录下来强行保活，从而保证标记的正确性。此时：A 是黑，B 是黑。

原创 如何设计一个高并发系统

高并发系统的核心目标是在保证高可用（High Availability）和数据一致性（Consistency）的前提下，最大化系统的吞吐量（Throughput）并降低响应时间（Latency）。一个优秀的架构师，需要在**性能（Performance）、可用性（Availability）和成本（Cost）**之间找到平衡点，并根据业务的发展阶段（初创期 vs 成熟期）选择最合适的技术方案。降级策略：在系统过载时，关闭非核心功能（如评论、推荐），保证核心业务（如下单、支付）可用2。

原创 MySQL 并行复制

在早期的 MySQL 版本中，从库（Slave）只有一个 SQL 线程负责重放中继日志（Relay Log），当主库（Master）并发写入压力较大时，从库的单线程无法跟上主库的速度，从而产生严重的 主从延迟（Seconds_Behind_Master）。如果事务 A 修改了 ID=1 的行，事务 B 修改了 ID=2 的行，即使它们在主库是先后提交的（时间上不重叠），MySQL 也会判断它们没有依赖关系（last_committed 可能会被标记为相同）。设置 Worker 线程的数量。

原创 MySQL 梳理

如果你的从库用的是 MyISAM 引擎，或者你想把数据同步到 Elasticsearch/Hadoop，它们根本看不懂 InnoDB 的物理 Redo Log（那是二进制的页结构），但它们能看懂 Binlog（标准的 SQL 或行数据）。如果你先用快照读（没幻读），然后自己手贱去 UPDATE 了一条别人刚插入的数据（因为 UPDATE 是当前读，不看版本），更新成功后，你的 Read View 里的 trx_id 变成了你自己的，下次再 SELECT 就能看到这条数据了——幻读产生。如果是新的，就跳过。

原创 Innodb一次更新动作

当客户端发起 COMMIT 时，为了保证 Redo Log（引擎层） 和 Binlog（Server层） 的一致性，MySQL 使用了 两阶段提交 (Two-Phase Commit, 2PC)。如果先写 Redo Log 成功，Binlog 失败：主库重启后通过 Redo Log 恢复了数据，但 Binlog 里没这条数据，导致从库（备库）丢数据。重启时，InnoDB 会读取磁盘上的 Redo Log，把没刷盘的修改重新应用（Replay）到内存中，恢复出宕机前的数据状态。（原值为 ‘Wang’）

原创 消息队列关键问题描述

Exchange（交换机）：他非常聪明，能根据信封上的各种规则（Routing Key），把信精准地分发给不同的少爷（队列）。如果没数据，Broker Hold 住请求（例如 5秒），一旦有新消息到达或超时，再返回结果。削峰填谷：面对双11的洪峰，它能抗住极高的并发（十万级 TPS），而且堆积了几亿条消息性能也不会下降（这是它比 RabbitMQ 强的地方）。业务功能丰富：它懂业务，支持事务消息（保证付钱和发货一致）、延时消息（下单30分钟不支付自动取消）、消息回溯（刚才发错了，重新发一遍）。

原创 即时编译整体梳理

JIT 知道哪些分支被真正执行了，哪些类型被真正加载了，从而能进行激进的“预测性优化”，这是静态编译器做不到的。OSR 的优势在于它打破了“以方法为单位”的编译限制，让正在运行中的代码也能被优化，确保了那些包含长循环但调用次数少的方法（如 main 函数或批处理脚本）也能获得极致的本地代码性能。逆优化 (Deoptimization)：如果后来加载了 LinkedList，之前的假设失效了，JIT 会立即通过“逆优化”退回到解释器模式，确保程序逻辑正确，然后再重新编译9。JIT 会分析对象的作用域。

原创 jvm运行时数据区& Java 内存模型

JMM 是一种抽象规范（JSR-133），它屏蔽了底层硬件（寄存器、缓存、内存）和操作系统（编译器优化、处理器重排序）的差异，保证 Java 程序在各种平台下对内存的访问都能达到一致的效果。Happens-Before 原则：JMM 定义的一系列天然的先行发生关系（如：启动线程的操作先于线程内的任何操作）。与虚拟机栈类似，区别在于它是为 Native 方法（JNI，如 C++ 编写的底层库）服务的。问题：线程 A 修改了变量，线程 B 无法立即看到，因为线程 A 改的是自己缓存里的副本。

原创 垃圾回收器

核心思想：G1 跟踪每个 Region 里面的垃圾堆积的“价值”（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region 610。如果在 Survivor 空间中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold。染色指针 (Colored Pointers)：将对象引用的元数据信息存储在指针的地址位上，而不是对象头中。

原创 JVM内存模型-常量池

这是为了省钱（内存）。菜谱里好几道菜都要用“盐”。如果每做一道菜都去买一包新盐太浪费了。于是厨房里有一个巨大的公共配料盒（堆内存），里面放着“盐”。不管哪道菜需要“盐”，都直接从这个盒子里拿，大家共用一份。当你决定做这道菜时，你把菜谱里的内容读进脑子里（内存的方法区）。此时，菜谱里的“切块鸡肉”这几个字，在你脑中变成了具体的“案板上的那块肉”（符号引用变成了直接引用）。就像你买的一本《家常菜谱》，它躺在书架上（硬盘里），里面写满了菜名（符号引用）和配料表（字面量）。在没开始做菜前，它只是死板的文字。

原创 Java相关记录文档

原创 Java常用开发工具

JDK 8+ (推荐): 彻底放弃 Date 和 Calendar，全面拥抱 java.time 包 (LocalDateTime, ZonedDateTime, Duration)。注：如果需要 skipNulls 功能，Guava 的 Joiner 依然有优势，JDK 需要 filter(Objects::nonNull)。原则：以下功能 Guava 虽然提供，但 JDK 8+ 原生实现已经足够好，新代码请直接使用 JDK。第三部分：已被 JDK 8+ 替代的特性 (迁移指南)Guava: 不涉及。

原创 List梳理

内存泄漏：如果你有一个巨大的 List，截取了一个小的 subList 并且长期持有，那么整个大 List 的数组都无法被 GC 回收（因为 subList 强引用了原数组）。而 LinkedList 内存分散，遍历时频繁发生 Cache Miss（缓存未命中），导致 CPU 必须频繁去主存取数，性能相差巨大。数据最终一致性：写入的数据，读线程可能不会立马读到（因为没切引用前读的还是旧数组），不适合实时性要求极高的场景。Vector：古老的线程安全数组（全同步，性能差，已淘汰）。

原创 Map梳理

JDK 1.8：尾插法。利用高低位指针（loHead/hiHead），不需要重新计算 Hash，直接判断 (e.hash & oldCap) 是 0 还是 1，0 留在原位，1 移到 原索引 + oldCap 位置。原理：当 n 是 2 的幂时，(n - 1) & hash 等价于 hash % n，但位运算效率更高。逻辑：如果 accessOrder 为 true，将当前节点 p 剪切下来，移动到双向链表的尾部。扰动函数：hash = (h = key.hashCode()) ^ (h >>> 16)。

原创 AQS原理概述

AQS（AbstractQueuedSynchronizer）是Java并发包的核心框架，用于构建锁和同步器。其核心思想是"状态（State）+队列（Queue）+CAS"，通过volatile state管理同步状态，CLH队列处理线程排队，利用CAS实现线程安全操作。资源获取流程包括尝试获取、入队、自旋/阻塞三个阶段；释放时会唤醒后继节点。AQS支持独占和共享两种模式，并提供了ConditionObject实现条件变量。LockSupport作为底层工具，通过"许可&quo

原创 Mybaits无法加载Xml文件

可以将接口与xml组合的方式<!-- Using classpath relative resources --><mappers> <mapper resource="org/mybatis/builder/AuthorMapper.xml"/> <mapper resource="org/mybatis/builder/BlogMapper...

原创 Eclipse+Maven+mybaits简单实例

文章目录一、数据库二、eclipse maven建立Java Web项目三、Web Demo1、实体类2、DAO接口和DAOImp实现类3、逻辑层4、控制器四、mybaits Demo1、pom.xml2、mybaits.xml3、flowerDaoImp.xml4、测试showAll 方法一、数据库CREATE TABLE `flower` ( `id` int(20) NOT NUL...

原创 编写servlet的404历程

文章目录1、首先是项目结构2、代码（1）HelloWorld(2)web.xml3、404解决（1）查看当前servlet包名类名引用是否正确（2）路径因是否正确（3）查看tomcat是否部署在eclipse中4、最后感谢党1、首先是项目结构2、代码（1）HelloWorldpackage com.robin;import java.io.IOException;import ja...

原创 Spring Aop Demo

文章目录一、aop二、xml方式1、定义接口类2、具体实现类3、切入类4、xml配置方式5、test二、Config配置方式1、配置类2、testeclipse 如何自动新建bean.xmlnew–>others–>spring Bean Configuration File–>命名一、aop1、 aop面向切面有两种方式：1 接口代理 2 cglib代理2、由于...

原创 redis-实现商品交易

文章目录一、结构设计二、用户挂卖商品三、购买商品四、test一、结构设计1、需要设计用户存储结构hash，来存放当前用户具有的金钱数2、设计用户包裹set，里边存储了用户的所有商品3、设计交易区market：zset集合来存储，存储格式为item.user price用户流程：1、将自己拥有的商品放置到贸易区，并设定一定的价格，在放置过程中需要去查看当前商品是否有变动，因为redis...

原创 reids 模仿消息队列

文章目录一、消息队列二、Jedis资源池生成实例三、生产者四、消费者参考一、消息队列消息队列简单来说就是一个消费者生产者模型，消费消费资源，生产者生产资源，如何通过redis来实现消息队列，会发觉redis中list结构很适合处理这类问题，list类型可以用来在商城系统中表明某一个流程，将一个个流程以lpush的方式放入到list中，将结束的流程以rpop的方式结束当前路程。二、Jedi...

原创 redis实战--文章投票

确定投票系统结构1、hash来存储文章key:article：110titile:文章标题link:链接votes:投票数user：文章作者2、zset存储文章发布时间3、zset存储文章得分4、set集合存储每一篇文章的投票的用户vote:110user:1user:2考虑生成文章需要将文章属性以Map集合的形式传入到hash结构中，之后在对应score与time添...

原创 代理模式

文章目录一、静态代理二、jdk的动态代理1、实现jdk动态代理2、使用要点（1）为什么jdk动态代理只能针对于接口？（2）为什么调用InvocationHandler会自动执行invoke()函数？（3）为什么匿名内部类使用局部变量需要定义为final？三、cglib的动态代理1、实现cglib动态代理四、参照博客一、静态代理1、比如买房子，首先实现通用接口，buyhouse()2、目标类实...

原创 01背包问题

文章目录一、递归解决背包问题二、动态规划一、递归解决背包问题暴力递归，穷举出所有的可能性，在检索完所有物品，即index=nums.length时候决定是否更新最大值1、当物品体积小于等于当前背包容量，选择放或者不放2、当物品体积大于，只能选择不放该物品//递归解决背包问题 public int getMaxValue(int[] weight, int[] value, int ...

原创 HTTP协议

文章目录一、Http协议过程1、Url输入地址2、DNS解析3、request请求1、请求行2、请求头部3、空行+请求正文（Get无请求正文）4、response请求1、状态行：协议版本、状态码、状态描述2、响应头3、空行+响应正文（HTML网页）5、获取HTML对应的资源（JS、css、图片）6、浏览器对网页进行渲染并显示二、长连接与短连接1、短连接2、长连接三、带流水与不带流水1、不带流水2、...

原创 工厂模式

文章目录一、简单工厂模式Demo二、工厂方法模式1、工厂方法模式简介2、工厂方法模式结构2、Demo三、抽象工厂模式1、抽象工厂方法简介2、抽象工厂方法结构3、Demo一、简单工厂模式简单工厂模式就是为了避免直接new对象，不需要去关注怎么生成该对象，用户只需要传入对应的参数就可以1、Iproduct:定义抽象产品类的公共方法2、Product:定义具体的产品类，实现抽象类中的方法...

原创 观察者模式

文章目录一、观察者模式二、订阅/发布模式（push模式）三、pop模式拉取模式四、标准模式（继承现有接口和抽象类）五、引用一、观察者模式观察者的通俗理解可以参考订阅发布的方式，每一个订阅内容，一旦被观察对象内容改变就会向观察者发送消息，告诉观察者修改了内容或者是观察者获取最新内容Subject：抽象主题（抽象被观察者），抽象主题角色把所有观察者对象保存在一个集合里，每个主题都可以有任意数...