- 博客(52)
- 收藏
- 关注
RSS订阅原创 【JVM】JVM内存结构
区域线程共享性核心存储内容生命周期是否需要GC虚拟机栈私有栈帧（局部变量表、操作数栈等）随线程生灭不需要本地方法栈私有本地方法的栈帧随线程生灭不需要程序计数器私有当前线程执行的字节码指令位置随线程生灭不需要堆共享new出来的对象、数组随对象生灭（可跨线程）需要方法区（元空间）共享类元数据、静态变量、常量池随类加载/卸载生灭部分需要。
2025-11-09 23:25:29
909
原创 【JVM】Java为啥能跨平台？JDK/JRE/JVM的关系？
这里要提一句：Java不是纯“解释执行”，还会用到JIT（Just-In-Time 即时编译器）——热点代码（频繁执行的代码）会被JIT编译成机器指令缓存起来，下次执行直接用，不用重复解释，这样能提升性能。Java代码执行时，会遇到一些“Java做不了”的操作（比如操作硬件、底层IO、线程调度），这些操作都是用C/C++写的“本地方法”，存放在本地方法库中。我们写Java代码时，不是一上来就写 .class 文件的，我们写的是 .java 文件，而 .java 文件需要用。
2025-11-06 21:33:42
1564
原创 【MQ】MQ消息可靠性：丢消息怎么办？消费失败怎么重试？
对于核心业务（比如支付、订单），要做“定时对账”：比如每天凌晨对比“MQ发送的消息日志”和“业务处理成功的日志”，如果发现“MQ发了但业务没处理”的消息，就触发“数据补偿”——重新调用业务接口处理，确保最终所有消息都被正确处理。最后，消费者还没消费就丢消息的问题，要使用消费者的 ACK 机制 —— 消费者必须消费完消息后，再给 MQ 发送 ACK，这样就算消费者中途出问题，MQ 没收到 ACK，还会重新发送消息。MQ收到消息后，如果没做持久化，突然宕机或重启，内存里的消息就会丢失。消息消费失败了怎么办？
2025-11-06 16:29:47
1193
原创 【MQ】MQ怎么保证消息顺序性，一定能保证消息顺序性吗
比如原本处理分区 A 的消费者 A，变成了消费者 B，消费者 A 已经拉取但没处理的消息，会被消费者 B 重新拉取，甚至 B 可能从更早的位置重新拉取消息，这就可能导致乱序，还会引发幂等性问题。如果没做幂等性，B会重复处理消息1，可能导致“重复支付”“重复发货”的问题，看似是重复消费，实则也会破坏业务逻辑的“隐性顺序”（比如重复发货在正常发货之后，逻辑上也是乱的）。局部有序就是说，同一个订单的 “下单→支付→发货” 有序就够了，同一个订单的消息要保证顺序，不同订单的顺序性不需要保证，这就是局部有序。
2025-10-23 14:55:54
984
原创 【LeetCode】142. 环形链表 II
留在相遇点，两指针以相同速度（1步/次）移动。根据数学推导，两指针会在环入口相遇，此时返回该节点。指针再次到达，则链表中存在环。为了表示给定链表中的环，评测系统内部使用整数。如果链表中有某个节点，可以通过连续跟踪。链表中有一个环，其尾部连接到第二个节点。链表中有一个环，其尾部连接到第一个节点。，返回链表开始入环的第一个节点。来表示链表尾连接到链表中的位置（，仅仅是为了标识链表的实际情况。返回索引为 1 的链表节点。返回索引为 0 的链表节点。如果链表无环，则返回。，则在该链表中没有环。
2025-10-15 11:08:14
965
原创 【LeetCode】146. LRU 缓存
/ 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}lRUCache.put(4, 4);// 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}lRUCache.put(2, 2);// 缓存是 {1=1, 2=2}// 返回 -1 (未找到)lRUCache.get(1);// 返回 -1 (未找到)lRUCache.put(1, 1);// 缓存是 {1=1}lRUCache.get(1);
2025-10-13 18:20:06
921
原创 【MQ】RabbitMQ：架构、工作模式、高可用与流程解析
这和Kafka的多副本机制基本上是类似的，相当于对队列做多个副本，你写消息到某个队列的时候，它就可以把这个消息自动同步到其他节点的队列上，其实就是一种多副本的机制，你也可以理解为是一种主从或者主备的机制。的概念，消息需要被发送到某个Topic下面，然后实际存储到某个队列里面，但是队列这个概念实际上是对用户屏蔽的，用户实际感知的其实是消息和Topic，但RabbitMQ的设计是完全不一样的。：收消息，和 Broker 连起来，订阅指定的队列，拿到消息后就去执行业务逻辑，比如处理订单、发通知。
2025-10-13 09:55:07
1378
原创 【并发编程】详解volatile
简单地说：volatile是“轻量级同步手段”，只解决可见性和有序性，适合变量的“单次读/写”场景；这时候，volatile就能派上用场——它是Java提供的。的操作是“单次写”（线程B）和“单次读”（线程A），没有原子性问题，用volatile保证可见性即可，性能比synchronized高。这是volatile最常用的场景——用一个volatile变量作为“线程间的信号开关”，控制线程的启动、停止或执行逻辑切换。这样一来，所有线程操作的都是主内存的“最新值”，不会出现“一个改了、一个没看见”的情况。
2025-10-09 16:37:02
1070
原创 【LeetCode】25. K 个一组翻转链表
是一个正整数，它的值小于或等于链表的长度。你不能只是单纯的改变节点内部的值，而是需要实际进行节点交换。的整数倍，那么请将最后剩余的节点保持原有顺序。个节点一组进行翻转，请你返回修改后的链表。额外内存空间的算法解决此问题吗？
2025-10-05 11:03:59
373
原创 【LeetCode】46. 全排列
给定一个不含重复数字的数组nums，返回其所有可能的全排列。你可以按任意顺序顺序返回答案。示例 1：输入：nums = [1,2,3]输出：[[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]示例 2：输入：nums = [0,1]输出：[[0,1],[1,0]]示例 3：输入：nums = [1]输出：[[1]]
2025-10-04 20:09:11
1044
原创 【LeetCode】92. 反转链表 II
输入：head = [1,2,3,4,5], left = 2, right = 4。这种方法先定位到反转范围，然后用标准的三指针反转法完成局部反转，最后重新连接链表。在需要反转的区间里，每遍历到一个节点，让这个新节点来到反转部分的起始位置。这种方法先完整反转局部链表，再进行连接，逻辑更符合常规的链表反转思路。输入：head = [5], left = 1, right = 1。的链表节点，返回 反转后的链表。输出：[1,4,3,2,5]
2025-10-04 19:41:35
1025
原创 【LeetCode】25. K 个一组翻转链表
是一个正整数，它的值小于或等于链表的长度。你不能只是单纯的改变节点内部的值，而是需要实际进行节点交换。的整数倍，那么请将最后剩余的节点保持原有顺序。个节点一组进行翻转，请你返回修改后的链表。额外内存空间的算法解决此问题吗？
2025-10-04 10:59:01
986
原创 【LeetCode】206. 反转链表
两种方法都能有效解决反转链表问题，实际应用中迭代法更为常用，因为它的空间效率更高。链表可以选用迭代或递归方式完成反转。你能否用两种方法解决这道题？这里我们主要实现迭代法，它更加直观且空间效率更高。，请你反转链表，并返回反转后的链表。
2025-10-04 10:58:42
609
原创 【LeetCode】146. LRU 缓存
/ 该操作会使得关键字 2 作废，缓存是 {1=1, 3=3}lRUCache.put(4, 4);// 该操作会使得关键字 1 作废，缓存是 {4=4, 3=3}lRUCache.put(2, 2);// 缓存是 {1=1, 2=2}// 返回 -1 (未找到)lRUCache.get(1);// 返回 -1 (未找到)lRUCache.put(1, 1);// 缓存是 {1=1}lRUCache.get(1);请你设计并实现一个满足。的平均时间复杂度运行。
2025-10-04 10:58:22
821
原创 【LeetCode】3. 无重复字符的最长子串
请注意，你的答案必须是 子串 的长度，“pwke” 是一个子序列，不是子串。解释: 因为无重复字符的最长子串是 “abc”，所以其长度为 3。解释: 因为无重复字符的最长子串是 “wke”，所以其长度为 3。解释: 因为无重复字符的最长子串是 “b”，所以其长度为 1。这种方法只需一次遍历，时间复杂度为 O(n)。输入: s = “abcabcbb”s 由英文字母、数字、符号和空格组成。，请你找出其中不含有重复字符的。输入: s = “pwwkew”输入: s = “bbbbb”
2025-10-03 19:15:09
263
原创 【MQ】手把手带你从零设计消息队列
比如“订单成功Topic”分3个分片，分片1存在Broker1（主）+Broker2（从），分片2存在Broker3（主）+Broker4（从），分片3存在Broker5（主）+Broker6（从）——每个Broker只存1/3的消息，容量和写压力都分散了。下游服务作为“消息消费者”，监听队列消息。我们的消息队列可能不止有一个Topic，而是有多个Topic（比如“订单成功Topic”“支付成功Topic”），所以需要在外面包一层来管理多个Topic——这个管理Topic的组件，就叫“Broker”。
2025-10-03 11:23:22
1484
原创 【MQ】3种方案搞定MQ消息幂等性，避免重复消费
消费者从MQ拉取消息后，会先处理业务（比如更新订单状态、扣减库存），处理完再给MQ发“ACK确认”（表示消息已处理，MQ可以删除消息了）。但如果消费者处理完业务，还没发ACK就宕机了（比如服务器断电、进程崩溃），MQ会默认“消息没处理完”，等消费者重启后，会再次把这条消息推给消费者。MQ没收到ACK，等消费者重启后，又把“扣减库存”的消息推过去，导致库存被重复扣减。其实你会发现，上面3种方案不仅能解决MQ消息幂等，也能解决“接口幂等”（比如用户重复点击提交按钮，导致接口被重复调用）。不是MQ不想做，而是。
2025-10-03 10:09:35
1729
原创 【Redis】Redis集群深度解析
有了主从为什么还要集群？Gossip协议的逻辑很像“谣言扩散”——每个节点都像“传话的人”，周期性地把自己知道的信息传给其他节点，其他节点再继续传播，最终所有节点的信息会达成一致。它的优势是“去中心化”，没有单一的“监控节点”，避免了哨兵的“单点故障”风险。Redis集群不需要哨兵，而是靠Gossip协议和“节点投票”实现故障自动转移，具体处理逻辑分“从节点挂了”和“主节点挂了”两种情况。集群中有多个节点，节点之间需要实时同步“节点状态”（比如哪个节点存活、哪个槽由哪个节点负责），Redis用的是。
2025-10-03 10:08:57
937
原创 【Redis】Redis高可用：主从复制与哨兵机制详解
主从复制解决了“读写分离”和“数据备份”，但有个致命问题：一旦主节点宕机，所有写请求都会失败，此时需要人工从多个从节点中选一个“升级为主节点”，再修改其他从节点的同步目标（指向新主节点），最后通知业务端切换写请求地址——整个过程耗时且容易出错，无法满足“高可用”的实时性要求。为了避免误判，哨兵会遵循“少数服从多数”的原则：当一个哨兵判断主节点“主观下线”后，会向集群中其他所有哨兵发送“询问请求”，问“你认为主节点是不是宕机了？故障转移需要一个“负责人”（哨兵leader），不能所有哨兵同时操作。
2025-10-03 10:08:20
852
原创 【Redis】Redis的5种核心数据结构和实战场景对应（在项目中的用法）
若 Redis 版本较高，可用 Stream——Stream 是 Redis 高版本专门的消息队列工具，功能更丰富，更接近完整的消息队列，和正式 MQ 相比还有缺陷，但整体已好很多，不想引入重 MQ 的话，用 Stream 或 List 都可以。比如记录不同地区的视频访问量，以视频 ID 为 key，地区为 field，访问次数为 value，访问一次就自增一次，实现不同地区视频访问量的记录。以网页路径或视频 ID 为 key，次数为 value，访问一次就自增一次，实现记录器效果。
2025-10-02 17:36:05
1249
原创 【并发编程】彻底搞懂Java内存模型 JMM：从底层原理到并发问题解决
如果操作 A操作 B，那么：操作 A 的执行时间一定在操作 B 之前（逻辑上的先后，不是物理时间，比如 A 在 CPU1 执行，B 在 CPU2 执行，物理时间可能重叠，但逻辑上 A 先完成）；操作 A 的结果，必须对操作 B 可见（比如 A 修改了count=0，B 读count时一定能拿到 0）。简单说，happens-before 就是 JMM 给程序员的 “承诺”：满足这个关系，就不用操心可见性和有序性问题。
2025-10-02 16:23:55
1277
原创 【MySQL】MVCC：从核心原理到幻读解决方案
事务 A：再查select * from user where name=‘AA’，就能看到 age=20 的数据 —— 这更诡异：快照读不到，却能修改，修改后又能读到，本质也是 “先快照读，再当前读” 导致的幻读。比如事务 A 第一次查id>100的数据有 5 条，事务 B 新增了 1 条id=101的数据并提交，事务 A 再查id>100的数据，还是 5 条（快照读看不到新增的 1 条），避免了幻读。事务 A 改数据时，事务 B 不能读 —— 这种方式能避免所有并发问题，但性能极差，实际业务中很少用。
2025-10-02 15:02:10
1066
原创 【MySQL】SQL执行流程：当你敲下回车，SQL语句在数据库中究竟经历了什么？
连接器：建立TCP连接，校验账号密码和权限——“打通和数据库的电话”。查询缓存：检查SQL是否执行过，有缓存直接返回——“看看家里有没有剩西红柿”（MySQL 8.0已删除）。解析器：拆语法、验正确性、生成语法树——“搞清楚要吃什么、吃多少”。优化器：制定最优执行计划（走索引还是全表扫描）——“规划最快的买西红柿路线”。执行器：调用存储引擎执行SQL，返回结果——“去菜市场把西红柿买回来”。
2025-10-02 12:45:57
1013
原创 【MySQL】数据库事务深度解析：从四大特性到隔离级别的实现逻辑
低隔离级别（读未提交、读已提交）：性能高，但一致性弱；高隔离级别（可重复读、串行化）：一致性强，但性能损耗大；而InnoDB通过MVCC技术，在可重复读级别实现了"强一致性"与"高性能"的平衡，这也是其成为MySQL默认存储引擎的核心原因之一。
2025-10-02 12:20:08
1090
原创 【LeetCode】912. 排序数组、手撕快速排序
是一个很好的选择，它的平均时间复杂度为 O(n log n)，在实际应用中表现优异。数组排序后，某些数字的位置没有改变（例如，2 和 3），而其他数字的位置发生了改变（例如，1 和 5）。对于本题，快速排序是综合性能较好的选择，既保证了高效性，又易于理解和实现。的情况下解决问题，时间复杂度为。请注意，nums 的值不一定唯一。，并且空间复杂度尽可能小。，请你将该数组升序排列。
2025-09-24 14:54:15
519
原创 【Redis】Redis 缓存更新策略&数据库一致性问题详解
所以综上所述, 你想保证数据库和缓存的这个一致性, 几乎是完全不可能的, 我们现有的手段, 只能说尽可能的去保证 缓存和数据库在绝大多数情况下是一致的，然后呢给数据设置一个过期时间，即便在非常非常非常极端的情况下不一致了, 那也够能够让这个脏数据过期失效, 不至于说脏数据就一直在。
2025-09-24 10:43:59
1387
原创 【Redis】缓存击穿、缓存穿透、缓存雪崩的解决方案
限流：通过锁、中间件控制访问数据库的请求数（如击穿的互斥锁、雪崩的限流）；拦截：在请求到达数据库前过滤无效流量（如穿透的参数校验、布隆过滤器）；高可用：保证缓存服务稳定+数据不集中失效（如雪崩的高可用架构、过期时间随机化）。实际业务中，需结合“数据一致性要求”“并发量”“业务场景”选择合适方案（如金融场景优先互斥锁，直播场景优先逻辑过期），必要时可组合多种方案（如布隆过滤器+缓存空值应对穿透），最大化保障系统稳定性。
2025-09-23 19:49:18
762
原创 【Redis】Redis持久化机制：从原理到实践详解
优势劣势恢复速度快：加载二进制快照文件直接入内存，无需解析命令数据安全性低：间隔性持久化，可能丢失快照间隔内的数据快照文件体积小：二进制格式压缩率高，便于备份/迁移高数据量下快照耗时：全量写入磁盘，IO 成本高BGSAVE仅 fork 时短暂阻塞频繁执行风险高：易引发 CPU/IO 瓶颈优势劣势数据安全性高：按秒/实时刷盘，丢失数据少恢复速度慢：重启需逐条执行命令，数据量大时耗时久日志可读性强：文本格式，可手动修改/恢复数据文件体积大：即使重写后，也可能比 RDB 快照大。
2025-09-23 19:07:42
1152
原创 【LeetCode】189. 轮转数组
给定一个整数数组nums，将数组中的元素向右轮转k个位置，其中k是非负数。向右轮转 1 步:向右轮转 2 步:向右轮转 3 步:向右轮转 1 步: [99,-1,-100,3]向右轮转 2 步: [3,99,-1,-100]O(1)
2025-09-23 15:40:44
910
原创 【LeetCode】64. 最小路径和
给定一个包含非负整数的m x n网格grid，请找出一条从左上角到右下角的路径，使得路径上的数字总和为最小。每次只能向下或者向右移动一步。7因为路径 1→3→1→1→1 的总和最小。12。
2025-09-23 10:42:21
547
原创 【LeetCode】82. 删除排序排序链表中的重复元素 II
给定一个已排序的链表的头 head ， 删除原始链表中所有重复数字的节点，只留下不同的数字。返回 已排序的链表。示例 1：输入：head = [1,2,3,3,4,4,5]输出：[1,2,5]示例 2：输入：head = [1,1,1,2,3]输出：[2,3]提示：链表中节点数目在范围 [0, 300] 内题目数据保证链表已经按升序 排列。
2025-09-23 09:56:40
439
原创 【LeetCode】3. 无重复字符的最长子串
给定一个字符串s，请你找出其中不含有重复字符的 最长子串 的长度。示例 1：输入：s = “abcabcbb”输出：3解释：因为无重复字符的最长子串是 “abc”，所以其长度为 3。示例 2：输入：s = “bbbbb”输出：1解释：因为无重复字符的最长子串是 “b”，所以其长度为 1。示例 3：输入：s = “pwwkew”输出：3解释：因为无重复字符的最长子串是 “wke”，所以其长度为 3。
2025-09-22 20:37:44
354
原创 【LeetCode】121. 买卖股票的最佳时机
给定一个数组prices，它的第i个元素prices[i]表示一支给定股票第i天的价格。你只能选择买入这只股票，并选择在卖出该股票。设计一个算法来计算你所能获取的最大利润。返回你可以从这笔交易中获取的最大利润。如果你不能获取任何利润，返回0。5在第 2 天（股票价格 = 1）的时候买入，在第 5 天（股票价格 = 6）的时候卖出，最大利润 = 6-1 = 5。注意利润不能是 7-1 = 6, 因为卖出价格需要大于买入价格；同时，你不能在买入前卖出股票。0。
2025-09-22 20:17:54
339
原创 【LeetCode】15.三数之和
不同的三元组是 [-1,0,1] 和 [-1,-1,2]。注意，输出的顺序和三元组的顺序并不重要。答案中不可以包含重复的三元组。唯一可能的三元组和不为 0。唯一可能的三元组和为 0。，判断是否存在三元组。
2025-09-22 17:27:33
427
原创 【MySQL】小白也能看懂的MySQL三大日志原理解析
事务执行过程中，每当修改一条数据，MySQL都会先把数据的原始版本记录到undo log中，同时通过“回滚指针”将这些不同版本的数据串联起来，形成“undo log版本链”。比如你把一条数据的age从20改成30，undo log会记录“这条数据的age原本是20”，并把这条记录和修改后的数据关联起来。INSERT操作：在undo log中记录新插入记录的主键ID。如果事务需要回滚，则根据该主键ID删除对应的记录。UPDATE操作：对于每次更新操作，会记录一条与之相反的undo log条目。
2025-09-22 10:21:38
1473
原创 【并发编程】线程池原理与实现
既想保证性能，又不想丢弃任务，其实可以借鉴操作系统的 “分层存储” 思想来解决。内存速度快但容量有限，磁盘容量大但速度慢，为了兼顾性能与数据安全，会把内存中关键数据持久化到磁盘；当无法加载所有数据到内存的时候，只加载必要的部分，待需要其他数据时再通过缺页中断从磁盘加载到内存。线程池的任务处理逻辑也能套用这个思路 ——通过自定义拒绝策略将任务持久化到可靠存储（MySQL、Redis、MQ），再通过机制触发任务恢复执行，实现“任务不丢失、系统不阻塞”。自定义拒绝策略：实现接口，在。
2025-09-16 20:35:55
871
原创 【并发编程】详解 ThreadLocal：底层实现、内存泄漏与并发场景应用
ThreadLocal看似简单，实则涉及底层存储、引用类型、GC机制、并发安全等多个知识点。本文围绕Java中ThreadLocal的实现机制、内存泄漏问题及其解决方案展开，同时涉及哈希冲突处理方法、ThreadLocal与锁的区别、死锁相关知识以及线程池的使用与优化。内容深入浅出，结合实际开发场景，对并发编程中的常见问题进行了系统性讲解。
2025-09-15 15:59:19
1127
原创 【并发编程】深入理解 AQS：从底层逻辑到 synchronized 对比
本内容围绕Java并发编程中的AQS实现原理展开，深入讲解了并发工具类的设计思想，包括状态变量state的设计、等待队列的构建、公平与非公平策略的实现机制，以及AQS在独占和共享两种模式下的应用。同时对比了ReentrantLock与synchronized的差异，分析了AQS相较于操作系统mutex的优势，适用于高并发场景下的线程同步控制。
2025-09-10 18:33:33
982
太原理工大学 期末速成 spring 软件设计与体系结构
2025-08-31
太原理工大学 SpringBoot期末笔记（22级）企业级应用开发框架技术
2025-08-31
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人