- 博客(52)
- 收藏
- 关注
RSS订阅原创 消息幂等性深度解析与实现方案
分层防护：不要依赖单一方案，至少要有2-3层幂等防护业务隔离：不同业务使用不同的幂等键策略监控告警：实时监控重复率，设置合理阈值定期清理：设置合理的过期时间，避免存储膨胀。
2025-12-09 21:49:58
1025
原创 消息丢失场景和解决方案
Broker存储阶段在Broker存储阶段防止消息丢失，核心在于通过配置确保消息持久化到磁盘并在多副本间同步。梳理了从单节点到高可用集群的详细配置方案。Broker存储阶段的可靠性是消息不丢的基石。核心决策是：通常建议从 SYNC_FLUSH主从架构起步，如需更高可用性则平滑升级到Dledger 集群。消费者处理阶段消费者阶段是消息不丢失的最后一道防线，也是实现业务一致性的关键。这个阶段的可靠性不依赖单一配置，而需要一套从处理流程、状态管理到容错设计的完整方案。在消费者阶段，确保消息不丢的黄金法则。
2025-12-07 22:37:31
653
原创 Semaphore 使用及原理详解
Semaphore 是一个强大的并发控制工具，它通过维护许可数量来控制对共享资源的访问。理解其基于 AQS 的实现原理有助于更好地使用它。在实际开发中，Semaphore 常用于限流、连接池管理、生产者-消费者模式等场景。
2025-12-01 22:58:49
874
原创 Nacos服务发现与配置中心工作机制
您的想法——“服务发现用 AP，配置中心用 CP”——是完全可行且是 Nacos 设计的初衷。在服务发现层面，像 Eureka 一样具备极高的可用性和伸缩性，能够应对服务实例频繁的上下线。在配置管理层面，像 ZooKeeper/Consul 一样提供可靠、一致的配置信息，避免因配置不一致导致的生产事故。
2025-11-12 19:45:38
304
原创 Oracle实时数据同步方案
将数据变更作为不可变的事件流发布出来，通过一个可靠的消息系统进行缓冲和分发，最后由消费者处理并投递到目标库。优点极高的灵活性与扩展性：可以轻松地增加新的数据消费者。可靠性强：基于Kafka的持久化消息传递。对源库影响极小：通过解析日志而非查询库表来获取数据。技术领先：构建了现代企业的实时数据流基础架构。挑战架构复杂：需要维护多个分布式组件，技术门槛高。端到端延迟：虽然性能很高，但链条比GoldenGate等直接同步工具要长，延迟会稍高一些。运维成本：需要专门的团队来维护Kafka集群和整个数据管道。
2025-11-11 21:12:17
1053
原创 ThreadLocal用法及实现原理解析
每个线程有自己独立的变量副本通过Thread内部的ThreadLocalMap实现key是ThreadLocal对象的弱引用，value是强引用需要手动管理内存，避免内存泄漏线程上下文传递（用户信息、事务管理等）线程安全的对象复用（如SimpleDateFormat）避免方法参数传递使用后务必调用remove()清理避免存储大对象考虑使用try-finally确保清理。
2025-11-03 19:50:48
133
原创 知名厂商全局唯一ID生成方案原理
方案核心优势核心风险适用场景简单可靠、性能高、无时钟问题ID不连续、数据库依赖绝大多数中小型互联网业务，对DB有管控能力的团队高性能、ID连续、云原生时钟回拨、ZK依赖容器化环境，时钟可靠（如使用NTP同步），有ZK运维能力性能极致、抗流量洪峰架构复杂、ID浪费、配置复杂超高并发、性能极度敏感的核心业务，有深厚技术实力的团队Seqsvr强一致性、业务透明、扩展性强系统复杂、成本高、网络依赖超大规模公司，有专职中间件团队，业务需要强一致性ID最终建议：当你不确定时，选择。
2025-10-15 17:01:37
827
原创 系统重构过程以及具体方法
识别问题是前提，自动化工具是你的侦察兵。具体修改是手段，从简单的重命名、提取函数，到复杂的引入设计模式，步步为营。最终，
2025-10-15 14:39:40
970
原创 MySQL事务隔离级别与锁机制详解
理解核心机制：MVCC处理读-写冲突，锁机制处理写-写冲突选择合适的隔离级别：默认"可重复读"适合大多数场景注意锁的粒度：良好的索引设计可以显著减少锁冲突预防死锁：保持事务短小，以固定顺序访问资源持续监控：定期检查锁等待和长事务问题深入理解这些机制，可以帮助你设计出既保证数据一致性又具备高并发性能的数据库应用。
2025-10-15 11:28:24
613
原创 ReentrantLock实现原理与使用风险
ReentrantLock 提供了比 synchronized 更灵活的锁机制，但同时也带来了更大的复杂性和责任。正确管理锁的生命周期- 确保在 finally 块中释放锁避免死锁- 使用超时机制和统一的锁获取顺序合理选择公平性- 非公平锁性能更好，公平锁避免饥饿控制锁粒度- 保持临界区代码简短考虑性能影响- 在高度竞争的场景下评估性能需求正确使用 ReentrantLock 可以构建高效、可靠的并发程序，但需要开发者对并发编程有深入的理解。
2025-10-15 10:15:50
362
原创 Java锁机制详解与应用场景
AQS是Java并发包的核心，大多数锁都基于AQS实现。核心组件state：同步状态，volatile修饰CLH队列：线程等待队列CAS操作：Compare And Swap，保证原子性// AQS简化实现原理// 获取锁if (!Java锁机制提供了丰富的工具来应对不同的并发场景。性能需求：读多写少还是写多读少功能需求：是否需要可中断、超时、公平性等特性复杂度：团队对锁的理解和使用能力维护性：代码的可读性和可维护性在实际开发中，应遵循"先用简单锁，再考虑复杂锁"的原则，优先使用。
2025-10-14 16:40:40
805
原创 Java内置锁（Synchronized）深度解析
/ 1. 使用专用锁对象synchronized(specificLock) { // 好：专用锁对象count++;// 2. 避免使用字符串常量作为锁// synchronized("LOCK") { // 危险：字符串常量在JVM中共享// }// 3. 减小同步范围// 在锁外执行准备工作// 只同步必要的临界区// 在锁外执行清理工作cleanup();// 4. 使用wait/notify的正确模式while (!try {
2025-10-14 16:11:11
968
原创 Java单例模式实现与风险分析
单例模式确保一个类只有一个实例，并提供一个全局访问点。单例模式虽然简单，但实现上有很多细节需要注意。推荐优先使用枚举单例，它简洁、安全且功能强大。如果必须使用类实现，静态内部类是不错的选择。无论哪种方式，都要注意线程安全、反射攻击和序列化问题。
2025-10-14 15:27:55
307
原创 synchronized锁升级过程详解
锁状态优点缺点适用场景偏向锁加锁和解锁不需要CAS操作，性能开销极低如果存在锁竞争，会带来额外的撤销开销只有一个线程访问同步块轻量级锁竞争的线程不会阻塞，提高了程序的响应速度如果始终得不到锁，自旋会消耗CPU追求响应时间，同步块执行速度非常快重量级锁竞争的线程不使用CPU自旋，不会消耗CPU线程阻塞，响应时间缓慢，用户态内核态切换慢追求吞吐量，同步块执行时间较长，竞争激烈核心思想：synchronized 不再是过去那个“笨重”的代名词。
2025-10-14 14:31:15
929
原创 volatile关键字原理
立即刷新到主内存：这主要是通过在写操作后强制刷新实现的。强制从主内存重新读取：这主要是通过在读操作前使缓存失效并强制从主内存加载实现的。禁止重排序：内存屏障的另一个核心作用就是建立指令之间的“先后”关系，阻止编译器和 CPU 跨越屏障进行重排序。因此，volatile是一种比更轻量级的同步机制，但它不保证原子性（例如i++这种复合操作在volatile下仍然不是线程安全的）。
2025-10-14 10:53:25
570
原创 MySQL分库分表方案及优缺点分析
一个仓库（单机数据库）里只有一个管理员（CPU/IO），货架（表）上的货物（数据）越来越多，来提货的工人（应用连接）也越来越多。：将访问频率高的“热点”字段（如用户ID、姓名、最后登录时间）放在一个表（主表），将访问频率低、占用空间大的“冷”字段（如用户详情、个人简介、设置项）放在另一个表（扩展表）。：单表数据量超过千万甚至亿级后，即使有索引，B+Tree的深度也会增加，磁盘IO次数增多，查询性能（特别是范围查询）显著下降。：数据迁移并验证完毕后，停用旧的分片规则，并清理旧分片上冗余的数据。
2025-10-13 15:23:42
631
原创 全局唯一ID生成方案详解
方案原理优点缺点/风险适用场景UUID标准算法随机生成简单、本地生成、性能高无序、存储空间大、不可读临时标识、日志跟踪、非DB主键DB自增ID数据库单机自增简单、递增强依赖DB、扩展性差、有性能瓶颈单机小型应用DB号段模式从DB批量获取ID号段高性能、递增、扩展性好依赖DB（频率低）、ID不连续主流方案，如订单、交易等大部分业务Redis INCRRedis原子递增性能高、递增强依赖Redis、持久化数据丢失风险高并发短链、活动ID等雪花算法时间戳+节点+序列号高性能趋势递增。
2025-10-13 15:19:10
760
原创 一致性哈希作为水平分片的路由规则
场景普通哈希取模一致性哈希3节点→4节点75%数据需要迁移仅 ~25%数据需要迁移数据分布均匀均匀（配合虚拟节点）实现复杂度简单中等扩容成本极高很低平滑扩容：增加节点时只影响局部数据，不会"牵一发而动全身"负载均衡：通过虚拟节点技术保证数据均匀分布容错性：节点故障时，只影响该节点负责的数据区间可预测性：数据迁移的范围是可预测和控制的实际应用示例Redis Cluster 使用类似一致性哈希的分片Cassandra、DynamoDB 等分布式数据库都采用这种方案。
2025-10-13 14:01:09
925
原创 分布式锁提前过期解决方案分析
没有银弹，只有组合拳。标准场景（绝大多数情况）方案组合看门狗自动续期 + 合理设置超时时间技术选型：直接使用Redisson等成熟客户端，它们已内置看门狗。理由：在简单性和可靠性之间取得了最佳平衡。高可用场景（要求锁服务自身高可用）方案组合RedLock + 看门狗续期 + 合理超时技术选型：使用 Redisson 的 RedLock 实现。理由：牺牲一部分性能，换取锁服务级别的可用性。金融/交易等核心场景（要求绝对的数据正确性）方案组合（看门狗续期 or RedLock）+ 防护令牌技术选型。
2025-10-13 10:02:01
547
原创 RedLock安全性问题及解决方案探讨
方案模型优点缺点/风险适用场景AP（异步复制）高性能，低延迟时钟跳跃、GC Pause 可能导致锁失效（理论风险）高性能、允许极低概率锁失效的场景（如避免重复计算的幂等性）。必须配合 Fencing Token用于关键业务。CP（一致性优先）高可靠，无时钟问题，通过 Session 和 Watch 机制更安全性能较低，部署复杂对锁的安全性要求极高的场景（如金融交易、主从选举）。数据库锁依赖DB一致性实现简单，无需新组件性能最差，数据库压力大。
2025-10-11 11:35:34
637
原创 MySQL分区分表实现方法详解
概念：这里的"分区"可以理解为更复杂的分片策略，例如按时间范围（如月份）分表，可能同时结合分库。这通常需要自定义分片算法。场景：订单表按月度分表，如。
2025-10-10 11:54:13
882
原创 线上OOM、CPU飙高
在调优部分，你不仅提到了具体参数，更重要的是阐述了参数背后的设计思想和权衡原则，这体现了你的实战经验。当锁竞争非常激烈时，上下文切换的次数会急剧上升，导致大量的CPU时间被用在“调度”上，而不是“执行有用的业务代码”上，从而表现为CPU使用率飙高。当一个持有锁的线程释放锁时，所有等待该锁的线程都会被唤醒，并试图去竞争这个锁。找到的繁忙线程堆栈，很可能是陷入了计算逻辑的死循环、低效的算法、或者锁竞争（大量的。：减少或避免Full GC的发生，因为它的停顿时间（STW）对延迟敏感的应用是致命的。
2025-10-09 21:49:05
596
原创 Spring框架面试问题及详细回答
特性控制反转 (IoC)依赖注入 (DI)本质一种设计原则、思想一种设计模式、实现技术关注点谁拥有控制权（容器 vs. 程序自身）如何提供依赖（注入 vs. 主动创建）关系目标实现该目标的手段为了实现程序的松耦合（IoC），我们采用了依赖注入（DI）这种方式。这就是它们之间的关系。3. Spring中依赖注入有哪几种主要方式？回答要点：构造器注入：通过类的构造函数注入依赖。推荐使用，因为它能保证依赖在对象创建时就可用，且对象是不可变的（immutable）。Setter注入。
2025-09-29 16:38:49
1064
原创 Spring AOP 实现机制源码分析
Spring AOP 的实现是一个复杂而精妙的系统，它通过多个组件的协同工作实现了强大的面向切面编程功能。
2025-09-28 21:20:32
907
原创 Spring依赖注入问题清单及解决方案
Bean定义检查是否正确使用注解组件扫描包是否正确是否存在多个同类型Bean依赖关系检查是否存在循环依赖注入时机是否合适作用域是否匹配配置检查属性文件是否正确加载属性值是否有默认值Profile配置是否正确生命周期检查初始化顺序是否正确资源是否正确释放测试检查测试配置是否正确Mock对象是否设置正确性能和安全检查是否使用构造器注入是否合理使用延迟加载。
2025-09-28 15:54:06
799
原创 Raft协议原理详解
Raft 协议通过清晰的角色分工、任期机制、随机化选举超时和严格的安全性规则，提供了一个强大而易于理解的分布式一致性解决方案。找主：通过心跳和随机超时机制选举出唯一的领导者。同步：所有客户端请求由领导者处理，并复制到大多数节点后才确认成功，保证数据一致性。保安全：通过选举限制和提交规则，确保即使在故障情况下，已提交的数据也绝不会丢失或回滚。特性RaftPaxos备注核心目标易于理解和实现理论正确性和简洁性Raft 是工程友好的领导权强领导者：任期内唯一领导者弱领导者。
2025-09-26 17:08:10
720
原创 RocketMQ面试问题与详细回答
对RocketMQ整体架构的基本理解。RocketMQ是阿里巴巴开源的一款分布式、队列模型的消息中间件，后捐赠给Apache基金会，成为顶级项目。它具有低延迟、高并发、高可用、高可靠的特点。Broker启动后，向所有NameServer注册自己的路由信息。Producer和Consumer启动后，从NameServer拉取路由信息。Producer根据路由信息，找到对应的Broker Master，将消息发送过去。Broker Master将消息存储到磁盘，并同步给Slave（如果配置了同步复制）。
2025-09-25 22:27:14
1135
原创 数据结构与设计模式面试问题及解答
这意味着，当系统需要增加新功能时，应该通过增加新的代码来实现，而不是修改已有的、已经测试稳定的旧代码。例如使用RxJava或Project Reactor，它基于观察者模式的思想，提供了强大的数据流处理和异步编程能力，非常适合构建高吞吐量的事件驱动系统。创建对象的逻辑是可能变化的（比如新增一种优惠券类型），工厂模式将这部分变化封装起来，客户端代码（如订单服务）无需修改，只需调用工厂即可。，两者协同工作，使得系统在增加新的优惠券类型（新的策略）时，几乎不需要修改业务核心逻辑，扩展性非常好。
2025-09-23 16:15:37
577
原创 MySQL与Redis面试问题详解
操作类型实现机制如何解决幻读快照读（普通SELECT）MVCC：事务使用固定的Read View读取undo log中的历史版本。因为读的是旧快照，根本看不到新插入的数据，自然无幻读。当前读（FOR UPDATE/UPDATE等）：锁住记录本身和周围的间隙。通过间隙锁物理上阻止其他事务插入新数据，从而杜绝幻读。简单理解过程：就像你（事务A）在看书时，拍了一张照片（Read View）。之后无论别人（事务B）在书上怎么涂改、加新页，你只看你的照片。照片上的内容自然不会变，你也不会看到新加的页。
2025-09-22 23:01:57
1070
原创 Java面试问题与解答：JUC与反射
动态代理是一种在程序运行期（Runtime）动态生成代理类和代理对象的技术，而无需像静态代理那样手动编写代理类的源代码。你可以把它想象成一个“万能中介你有某个对象（真实对象）：比如一个实现了接口的对象，它有addUser()等方法。你想在不修改这个对象代码的前提下，给它增加一些功能：比如在每次调用方法前记录日志，调用后计算耗时。你找到这个“万能中介”（动态代理）：你告诉中介：“嘿，这是我的对象和我想额外做的事（日志、耗时）”。中介在运行时凭空生成一个新的代理对象：这个新生成的对象也实现了接口。
2025-09-21 22:07:01
856
原创 Spring循环依赖问题
特性能否解决原因单例Bean + Setter/字段注入✅ 能依靠三级缓存提前暴露早期引用单例Bean + 构造器注入❌ 不能无法在构造完成前暴露引用原型（Prototype）Bean❌ 不能不使用三级缓存虽然Spring提供了强大的机制来解决循环依赖，但它本质上是一种代码的“坏味道”（Code Smell），说明你的类设计可能耦合过高，职责不够单一。最佳实践是：强制在编译期就发现循环依赖问题，迫使你重构代码。如果出现循环依赖，考虑是否可以通过提取公共逻辑到第三个类使用接口。
2025-09-21 10:32:38
949
原创 系统性能优化与日志处理方案面试问题
本文通过模拟一场深度技术面试，全面剖析了一个高性能日志优化方案。不仅涉及了RocketMQ、Redis等具体技术，更重点展现了面试官所关注的问题定位、技术选型、架构设计、权衡取舍、容错保障、监控运维和抽象升华等多个维度的能力。希望读者能以此为例，不仅准备好答案，更能培养出解决此类问题的思维模式，在未来的面试和工作中游刃有余。
2025-09-19 10:57:13
968
原创 网络协议与AI工具面试准备
考察点：对HTTP特性及常见实践的理解。优秀回答思路无状态：指协议本身不对请求和响应之间的通信状态进行保存。每个请求都是独立的，服务器不会记住之前的请求信息。管理状态的技术Cookie：最常用。服务器通过Set-Cookie头部将信息发送给客户端保存，客户端后续请求通过Cookie头部自动带回。Session：服务器端机制。在服务器创建Session对象存储用户数据，并通过一个唯一的Session ID（通常存放在Cookie中）关联客户端。Token（如JWT）：更现代的方式。
2025-09-18 22:03:02
740
原创 JVM与性能调优面试问题与回答
着色指针在指针中嵌入元数据，使得GC过程中对象的引用关系可以并发地被处理和修复，读屏障是“拦截”应用线程访问对象引用的操作，根据着色指针的状态进行必要的并发处理（如重定位对象）。而老年代GC（无论是CMS的并发标记清除还是G1/ZGC的标记整理/复制）需要处理整个老年代或大部分Region，标记过程复杂，且如果使用标记-整理算法，移动对象的成本很高。： 像堆一样，ZGC也可以使用类似“压缩指针”的技术，在堆更大时，使用某种间接寻址或多级页表的方式来扩展地址空间，同时保留指针中的元数据位。
2025-09-18 10:00:12
698
原创 Java I/O模型原理与应用场景详解
特性BIONIOAIO全称编程模型一个连接一个线程一个线程处理多个连接（Selector）订阅-通知（回调）阻塞类型同步阻塞同步非阻塞（多路复用）异步非阻塞吞吐量低高理论上最高复杂度低高最高可靠性高高高（但Linux支持弱）适用场景连接数少、固定高并发、短连接高并发、长连接、重操作。
2025-09-15 17:05:38
827
原创 ClassLoader原理与应用详解
摘要： ClassLoader是JVM的核心组件，负责动态加载类到内存中，其生命周期包括加载、验证、准备、解析、初始化等阶段。双亲委派模型确保核心库安全性和类唯一性，通过Bootstrap、Extension、Application三层加载器实现层级委托。实际应用中，ClassLoader支持热部署、模块化及非标准源加载，但需注意资源泄漏、类型转换等问题。理解ClassLoader机制对JVM调优、故障排查及高级功能开发至关重要。
2025-09-11 15:32:05
645
原创 JVM调优过程详解
工具核心作用关键输出/命令调优场景jps找PIDjps -l第一步，定位目标Java进程jstat监控GC、内存趋势核心工具，看GC频率、耗时、内存使用率，发现异常点jmap堆内存分析，抓取快照初步定位内存泄漏嫌疑犯；生成文件供MAT深度分析jstack线程分析，诊断卡顿、高CPU、死锁诊断线程状态、锁竞争、死锁、高CPU线程最佳实践流程使用jps或ps找到目标PID。使用持续观察GC健康状况。如果发现FGC频繁、O区只增不减 -> 怀疑内存泄漏-> 用初步查看，或用jmap -dump。
2025-09-10 21:03:02
994
原创 JVM垃圾回收机制与调优解析
收集器分代/区域算法线程模式目标适用场景年轻代/老年代复制/标记-整理单线程简单高效客户端、嵌入式ParNew年轻代复制并行与CMS配合与CMS搭配的服务器年轻代/老年代复制/标记-整理并行高吞吐量后台计算、批处理CMS年轻代/老年代标记-清除并行+并发低停顿B/S系统（已废弃）G1Region标记-整理并行+并发低停顿+高吞吐主流服务器应用Region染色指针等并行+并发超低延迟超大堆、极致延迟要求如何选择？小应用或客户端：直接使用默认或Serial。
2025-09-08 14:50:00
709
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人