- 博客(36)
- 收藏
- 关注
RSS订阅原创 进程 线程 协程基本概念和区别 还有内在联系
资源分配和拥有的独立单位，程序的一次执行实例CPU调度的基本单位，进程内的一个执行实体用户态的轻量级线程，可暂停/恢复的函数。
2025-10-29 23:35:48
274
原创 在RR级别下加锁情况
MySQL InnoDB锁机制解析摘要： InnoDB加锁遵循两大原则：1)基本单位是Next-Key Lock(记录锁+间隙锁组合)；2)仅锁定实际访问的索引项。等值查询时，唯一索引若记录存在则退化为记录锁，不存在则退化为间隙锁；非唯一索引会额外加右区间间隙锁。范围查询时，非唯一索引不会退化锁。覆盖索引可减少锁冲突，RC隔离级别禁用间隙锁。建议使用唯一索引更新、控制事务粒度、及时提交，并利用EXPLAIN分析执行计划。
2025-09-10 15:43:46
526
原创 update没加索引会锁全表？
InnoDB的UPDATE语句在WHERE条件未使用索引时会触发全表next-key锁（记录锁+间隙锁），阻塞其他事务。这是由于可重复读隔离级别下InnoDB通过索引项加锁防止幻读，非索引列更新会全表扫描加锁，且锁直到事务结束才释放。解决方案包括设置sql_safe_updates、强制使用索引和验证执行计划。关键点：无索引更新实质是对所有索引项加锁而非表锁，即使条件含索引列若优化器选择全表扫描仍会锁表，大表操作需特别注意避免业务停滞。
2025-09-10 14:00:27
355
原创 联合索引失效场景
联合索引是提升数据库查询性能的关键工具，但错误使用会导致其失效，引发全表扫描。主要失效场景包括：违反最左前缀原则（缺少最左列）、范围查询阻断后续列、对索引列运算/使用函数、隐式类型转换、OR连接非索引字段、LIKE左模糊匹配以及数据分布影响优化器选择。诊断方法建议使用EXPLAIN命令分析执行计划，重点关注type、key和Extra列。优化策略包括：将高选择性列放索引左侧、避免索引列运算、确保参数类型匹配、拆分OR条件查询等。合理设计联合索引可显著提升查询效率，但需平衡读写性能。
2025-09-10 10:16:42
630
原创 try-catch执行流程
摘要： finally块总会执行，影响返回值的方式因数据类型而异：基本类型返回的是值的副本（finally修改无效），引用类型返回的是对象地址（finally修改会影响返回对象状态，但重新赋值无效）。强烈不建议在finally中使用return，这会覆盖try/catch的返回值并可能掩盖异常。若try抛出未捕获异常，finally执行后异常继续抛出。核心原则：finally确保执行，但避免在其中使用复杂返回逻辑以保证代码清晰性。
2025-09-09 12:56:15
257
原创 java接口和抽象类有何区别
抽象类更像是一个不完全的类，为相关类提供公共基础和模板，侧重于代码复用和内部状态管理。接口更像是一个行为协议，定义了实现类应对外提供哪些服务，侧重于契约定义和解耦。现代Java设计（尤其是Java 8引入默认方法后）更倾向于 "面向接口编程"，优先考虑使用接口定义类型，以提高灵活性和可扩展性。抽象类则更适用于框架内部或存在明显继承关系的类族中，用于封装公共实现。在设计时，组合（通过接口）优于继承。
2025-09-06 23:17:06
1401
原创 %前置模糊查询优化
前置模糊查询（LIKE'%xxx'）存在无法利用索引、全表扫描的性能问题。优化方案包括：1）使用反向索引存储反转字段值；2）MySQL 5.6+采用全文索引；3）大数据量使用Elasticsearch等专业搜索引擎；4）创建联合索引；5）添加查询条件限制结果集。建议根据数据规模选择方案：小数据量用反向索引，百万级用全文索引，大数据量用专业搜索引擎。
2025-09-06 21:43:57
326
原创 ArrayList扩容原理
ArrayList扩容机制摘要： ArrayList默认初始容量为10，通过1.5倍系数扩容（如10→15）。扩容条件为添加元素时size+1>数组长度，核心步骤包括：计算新容量（考虑1.5倍原则和最小需求）、处理大容量限制、创建新数组并复制数据。扩容带来O(n)时间开销和内存浪费。优化建议：预估容量指定初始大小、提前调用ensureCapacity()、完成后使用trimToSize()释放多余空间。合理使用这些方法可显著提升性能。
2025-09-05 10:42:43
778
原创 rocketmq延时消息实现
RocketMQ的延时消息通过预定义18个延迟等级（1-18级对应不同延迟时间）实现，消息先存入内部主题SCHEDULE_TOPIC_XXXX对应队列。内置的ScheduleMessageService每100ms扫描队列，到期后将消息转回原始Topic投递。底层采用时间轮算法高效管理延迟任务，实现O(1)复杂度处理。5.0+版本支持自定义延迟时间，提供更灵活的场景支持。
2025-09-04 14:44:21
501
原创 为何不建议在producer端过滤消息
RocketMQ采用Broker端过滤来保持生产者和消费者的解耦性，主要提供Tag过滤和SQL92属性过滤两种方式。Tag过滤基于哈希匹配，高效简单；SQL92过滤灵活但消耗更多资源。建议优先使用Tag过滤处理简单分类，SQL92适用于复杂动态条件，尽量避免在消费者端过滤以节省资源。这种设计既保证了系统性能，又维护了消息系统的解耦特性。
2025-09-04 14:13:32
727
原创 如何处理RocketMQ消息堆积
摘要： 处理RocketMQ消息积压需分阶段应对： 1️⃣ 紧急处理：快速扩容消费者实例/线程，限流生产者，优先恢复服务； 2️⃣ 性能优化：异步化消费逻辑、启用批量处理、调整队列数与Broker参数（如SSD存储、异步刷盘）； 3️⃣ 长期预防：建立监控告警（Lag/TPS）、自动扩缩容机制，设置消息TTL与死信队列。 关键点：定位瓶颈（消费者/Broker/队列热点），按场景选择限流、重置位点或扩容策略，结合短期恢复与长期健壮性设计。
2025-09-04 12:33:15
648
原创 RocketMQ主从模式
摘要： RocketMQ的主从模式通过Master处理写请求、Slave复制数据并分担读负载，实现高可用。提供异步复制（ASYNC_MASTER，高性能弱一致）和同步复制（SYNC_MASTER，强一致低性能）两种模式，适应不同业务场景。数据同步通过TCP长连接和偏移量上报实现，但原生主从不支持自动故障转移，需依赖Dledger（基于Raft）提升可用性。建议异步复制搭配Slave读取，部署隔离主从节点，并监控同步延迟。关键业务可选用同步复制或Dledger确保数据一致性及自动容灾。
2025-09-04 10:43:04
892
原创 数据库主键选择策略分析
摘要：数据库自增主键在分布式系统中存在分库冲突、安全风险等问题；UUID则有存储大、无序性等缺陷。雪花算法虽优但仍有时钟回拨等局限。推荐方案：单机系统用自增主键，分布式系统采用改进版雪花算法（如Leaf），特殊场景可选用哈希ID或业务编号组合。NoSQL系统可充分利用特有ID机制。选择主键策略需综合考虑业务需求、数据规模和系统架构。（149字）
2025-09-01 20:40:03
459
原创 CAP 与BASE理论
摘要：CAP理论指出分布式系统无法同时满足一致性(C)、可用性(A)和分区容错性(P)，通常需在CP或AP之间选择。BASE理论则是对AP方案的延伸，通过基本可用、软状态和最终一致性来平衡性能与一致性。核心区别在于CAP强调强一致性，而BASE主张最终一致性。实际应用中，金融等场景适合CP系统如ZooKeeper，电商等对可用性要求高的场景则适合AP系统如Cassandra。两者共同指导分布式系统设计时的权衡决策。（149字）
2025-08-28 10:18:14
629
原创 Redis线程模型
它的核心是单线程的事件循环和命令执行，这保证了操作的原子性和极高的性能。它的辅助是多线程的网络 I/O 和后台任务处理，这帮助它克服了单线程在特定场景下的瓶颈，更好地适应现代多核硬件和高并发需求。这种“主线程单线程执行命令，多线程/多进程辅助处理I/O和耗时任务”的架构，是Redis能在高并发、低延迟场景下表现出色的关键原因。
2025-08-26 18:28:46
863
原创 Redis是单线程的，但是为什么还那么快？
Redis的单线程模型通过避免锁竞争、减少上下文切换、配合内存存储和I/O多路复用，将其在单核上的性能发挥到了极致。这使得它在处理高并发、低延迟、数据操作简单的场景（如缓存、会话存储、排行榜）时表现卓越。Redis 6.0及以后版本引入的多线程网络I/O，是为了更好地应对超高网络负载，但其命令执行的核心仍未改变，继续保持了单线程简化并发控制的优势。
2025-08-26 15:57:24
302
原创 快速搞懂Redis哨兵和分片集群
Redis哨兵模式和分片集群是两种不同的高可用解决方案。哨兵模式通过监控主从节点实现自动故障转移，适合读多写少、数据量不大的高可用场景；分片集群通过数据分片实现水平扩展，适合海量数据和高并发读写场景。哨兵配置简单但扩展性有限，分片集群扩展性强但配置复杂。选择方案需根据业务需求：重高可用选哨兵，需扩展选分片集群。
2025-08-26 12:07:03
1132
原创 快速搞懂红锁（redLock）和联锁(multiLock)
Redisson分布式锁机制对比：RedLock与MultiLock核心区别 Redisson提供两种分布式锁机制应对不同场景： RedLock（红锁） 目标：解决主从异步复制的锁丢失问题 要求：至少5个独立Redis主节点 成功条件：获取多数节点锁(N/2+1) 适用场景：高可靠性需求如金融交易 MultiLock（联锁） 目标：实现多资源原子性锁定 要求：同集群内的多个锁 成功条件：必须获取全部锁 适用场景：分布式事务如同时锁定订单/库存 关键区别： RedLock强调跨独立节点的高一致性，MultiL
2025-08-26 10:06:06
1223
原创 Redis pub/sub机制
Redis 的发布订阅（Pub/Sub）机制是一个简单高效的实时消息系统，其核心价值在于解耦和实时广播。选择它，通常是因为看中了其极低的延迟和实现的简便性，并能接受其无持久化、可能丢失消息的特点。对于需要更高可靠性、消息持久化、精确消费语义的场景，建议考虑使用 或其他专业的消息队列系统（如 Kafka、RabbitMQ）。
2025-08-26 09:32:04
1004
原创 Redisson中的分布式锁
Redisson 中的分布式锁，具体取决于你调用的加锁方法。下面我用一个表格帮你快速了解不同方法的行为，然后再详细解释其背后的机制和最佳实践。方法签名锁类型行为描述是否自动续期 (看门狗)备注当前线程，直到获取到锁。是 (默认30秒)最常用，需手动解锁直到获取锁，但看门狗续期，锁在指定的leaseTime后自动过期。否需确保业务在leaseTime内完成非阻塞（仅尝试一次）。成功返回true，失败返回false。是 (默认30秒)，在指定的。
2025-08-26 09:28:35
671
原创 一句话带你了解COW（Copy-On-Write）
COW（Copy-On-Write，写时复制）是一种广泛应用于计算机系统的优化策略，其核心思想是通过延迟数据复制操作来提升资源利用效率，尤其在内存管理、并发编程和持久化场景中表现突出。
2025-08-24 23:30:39
937
原创 Redis的RDB详解
RDB是Redis通过快照实现持久化的机制，将内存数据保存为紧凑的二进制文件（dump.rdb）。核心原理是通过fork子进程异步生成快照，利用写时复制技术保证数据一致性。支持自动触发（配置save规则）和手动触发（BGSAVE）。优点包括恢复速度快、文件体积小、对性能影响小；缺点是可能丢失最后一次快照后的数据，且大内存实例fork时可能阻塞。适用对数据完整性要求不高的场景，建议与AOF搭配使用，RDB用于定期备份和快速恢复，AOF保证数据实时安全。生产环境需合理配置触发规则、监控fork耗时并定期备份RD
2025-08-24 23:25:00
884
原创 Redis挂了怎么办？
：部署Prometheus+Grafana等工具监控内存、连接数等指标，设置阈值报警。：若无持久化或文件损坏，需从备份文件（如定时备份的RDB或AOF）中恢复数据。：建议同时启用RDB和AOF（混合持久化），平衡性能与数据安全性。若未运行，可能是服务崩溃或手动终止。：临时切换至Memcached等替代方案，需修改应用配置。，关注内存溢出（OOM）、持久化失败、权限错误等关键信息。：禁用缓存，直接访问数据库（性能下降但可保业务连续）。：若启用RDB持久化，检查。：若使用AOF，确保。
2025-08-24 09:57:16
447
原创 Stream流的今生后世
Java Stream API适用于多种数据结构：1) 集合框架中的List、Set和Map（需转换）；2) 对象数组和基本类型数组；3) 文件I/O、生成器函数等数据源；4) 特殊流类型如原始类型流、并行流和空流。Stream API提供统一操作接口，不论底层数据结构如何都能使用相同的流式处理方法，提升代码简洁性和执行效率。主要转换方式包括stream()、Arrays.stream()等，支持过滤、映射等操作。
2025-08-23 21:00:13
314
原创 Redis Bitmap详解：原理、应用与最佳实践
Redis中的Bitmap（位图）是一种基于String类型实现的特殊数据结构，它通过二进制位（bit）来高效存储和操作大量布尔值数据。
2025-08-23 19:22:32
1658
原创 SQL执行顺序详解
：根据连接类型（INNER/LEFT/RIGHT JOIN等）合并表数据。：首先确定数据来源，加载指定的表或视图数据。：应用连接条件（如JOIN操作中的条件），过滤不符合连接条件的记录。：对分组后的结果进行过滤（与WHERE不同，它可以使用聚合函数）：对连接后的数据集进行行级过滤，此阶段应尽可能减少数据量。：选择最终输出的列，此时才处理列表达式和别名。：按指定列对数据进行分组，为聚合计算做准备。：最后应用分页限制，返回指定范围的记录。：去除结果集中的重复行（如果指定）
2025-08-23 16:00:43
181
原创 快速读懂MVCC
摘要： MVCC（多版本并发控制）通过维护数据行的多个版本来实现无冲突的并发读写。其核心实现包括：1）隐藏字段（事务ID、回滚指针和隐藏主键）；2）undo日志记录数据变更历史，形成版本链；3）ReadView机制根据事务隔离级别决定可见性版本。不同隔离级别下ReadView生成策略不同，RC级别每次快照读生成新ReadView，RR级别则复用首个ReadView。这一机制有效解决了事务间的读写冲突问题。（149字）
2025-08-23 13:16:23
586
原创 一句话概括redo log工作流程
根据innodb_flush_log_at_trx_commit参数决定刷盘策略（默认1表示每次提交都刷盘）事务提交前，先将Redo Log Buffer中的日志标记为"Prepare"状态。同时将数据页的物理变更记录写入Redo Log Buffer（内存缓冲区）事务修改数据时，先在内存的Buffer Pool中更新数据页（产生脏页）在Binlog写入成功后，将Redo Log状态改为"Commit"系统重启时，从最近的Checkpoint开始重放Redo Log。Redo Log通过。
2025-08-23 13:06:43
181
原创 mysql索引失效常见原因
：MySQL 8.0+支持索引跳跃扫描，当首列唯一值较少时可能绕过此限制。：覆盖索引（查询字段全在索引中）时，左模糊可能仍走索引扫描。（如性别字段）即使有索引，优化器也可能选择全表扫描。可能导致索引失效，尤其当NULL值占比高时。：B+树索引不存储NULL值的有序信息。无索引），优化器会放弃索引选择全表扫描。）都会破坏索引的有序性，导致全表扫描。复合索引未按定义顺序使用（如索引。）会触发类型转换，导致索引失效。）会导致索引部分或完全失效。）会使索引失效，仅右模糊（），其右侧列的索引会失效。
2025-08-19 22:44:46
530
原创 mysql索引详解
MySQL索引是数据库高效运行的关键组件，它通过特定的数据结构加速数据检索，显著提升查询性能。本文将全面解析MySQL中的各种索引类型，包括它们的、、以及，帮助您在实际开发中合理选择和使用索引。
2025-08-11 22:23:48
756
原创 缓存一致性解决方案选择
6.这种方案，主要是监听 MySQL 的 Binlog，然后通过异步的方式，将数据更新到 Redis，这种方案有个前提，查询的请求，不会回写 Redis。这个方案，会保证 MySQL 和 Redis 的最终一致性，但是如果中途请求 B 需要查询数据，如果缓存无数据，就直接查 DB；这个方案，是实时性中最好的方案，在一些高并发场景中，推荐这种。，比如 binlog + kafka（canal/各种消息队列），数据的一致性也可以达到秒级；，删除 Redis 如果失败，可以再多重试几次，否则报警出来；
2025-03-17 13:50:41
778
原创 hashMap--put方法快速读懂
4. 存在数据，说明发生了 hash 冲突，继续判断 key 是否相等，如果相等，用新的 value 替换原数据(这里onlyIfAbsent 为 false)；6. 如果不是树型节点，则采用尾插法，把新节点加入到链表尾部；在看put方法的源码之前，我们需要先知道额外的一些方法，resize() -->>扩大两倍容量。5. 如果不相等，判断当前节点类型是不是树型节点，如果是树型节点，创建树型节点插入红黑树中；1. 判断table是否为空，如果空的话，会先调用resize扩容；0.调用putval方法；
2025-03-17 10:09:28
309
原创 缓存穿透--最佳实践
如果存在qps几百上千的情况，还是推荐使用后者，布隆过滤器的收益相当高，我曾用rocketMQ和布隆过滤器实现对接口的性能15倍提升，关于布隆过滤器的详细使用的和假阳性后续可能会出文章继续讲解。相信大家在进行项目开发和学习redis过程中，总是会遇到一些技术方案上的抉择问题，对于缓存穿透问题，无非就是某个数据在缓存和数据库中都没有，然后很多请求直接打到数据库，对数据库造成巨大压力。1.>>--设置空值，并设置过期时间-->> 减少对数据库请求，当然这种方案有一定问题，但对大部分qps低的场景已经够用。
2025-03-04 08:55:07
248
原创 springboot中的Parent项目中Maven依赖爆红
在依赖管理中有依赖爆红是正常现象（爆红但是可以正常运行），如果在子moudle中有引用该依赖才会去进行下载。
2025-01-27 17:54:34
447
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人