- 博客(45)
- 收藏
- 关注
RSS订阅原创 数据库主键选型：为什么别用自增 ID？
自增 ID：只适合玩具项目，生产环境核心表绝对不能用纯 UUID：比自增 ID 更糟糕，绝对不要作为主键雪花算法：企业级首选，兼顾性能、唯一性和扩展性存储类型：永远用BIGINT存储 ID，不要用VARCHAR。
2026-05-22 00:14:58
537
原创 ThreadPoolExecutor 7 个核心参数详解
/ 获取CPU核心数// 创建自定义线程池cpuCoreNum, // 核心线程数：CPU核心数cpuCoreNum * 2, // 最大线程数：2*CPU核心数60L, // 空闲存活时间：60秒TimeUnit.SECONDS, // 时间单位：秒new ArrayBlockingQueue<>(1000), // 有界队列，容量1000。
2026-05-21 22:47:03
443
原创 synchronized 底层原理深度详解
通过 Monitor 中的_count计数器实现，同一线程加锁计数 + 1，解锁 - 1，为 0 才真正释放。
2026-04-02 15:03:44
221
原创 支付场景并发死局：订单超时与支付回调同时到达，怎么彻底解决？
支付并发死局的根源是查询与更新非原子，解决方法就是：数据库原子更新 + 状态机约束 + 回调优先 + 幂等 + 延迟队列 + 对账兜底。只要按这套做，订单超时与支付回调同时到达就再也不是问题。
2026-04-01 21:37:51
603
原创 Java JDBC核心概念与实战详解
用于实现 Java 程序与各类关系型数据库（MySQL、Oracle、PostgreSQL 等）的交互。JDBC（Java Database Connectivity）是 Java 提供的一套。以 MySQL 为例，实现 “查询用户 + 新增用户” 的完整流程，包含。避免 SQL 注入）。
2026-03-07 12:41:42
389
原创 MySQL数据不丢失的5大核心机制
核心层：redo log（WAL 机制）+ 双 1 配置，保证事务提交后数据可恢复，宕机不丢失；恢复层：崩溃恢复流程，通过 redo log 重放、undo log 回滚，保证重启后数据一致；物理层：定期备份 + 主从（半同步）复制，解决磁盘损坏、主库故障的场景。简单来说，MySQL 遵循 “日志先行、异步刷盘、崩溃可恢复、数据可备份” 的原则，从内存到磁盘、从运行时到物理介质，全方位规避数据丢失风险。
2026-03-06 00:00:56
549
原创 HashMap与Hashtable的关键区别
核心差异HashMap非线程安全、支持 null、单线程性能高；Hashtable线程安全（全表锁）、不支持 null、并发性能极差。使用选择：单线程用HashMap，多线程安全场景优先用（而非 Hashtable）。设计层面：Hashtable 是早期设计的产物，哈希计算、扩容、锁机制均无优化，现已被淘汰，仅作历史知识点了解即可。
2026-03-05 23:43:59
359
原创 ConcurrentHashMap深度解析
的核心价值是多线程安全 + 高并发性能，相比传统的线程安全哈希表（Hashtable），它通过精细化锁（分段锁 / JDK1.8 桶锁）和 CAS 机制大幅提升并发效率。JDK 1.8 是 ConcurrentHashMap 的主流实现，抛弃分段锁，采用 “CAS + synchronized + 红黑树”，锁粒度缩小到单个桶，并发性能更优。与 HashMap 的核心区别在于：线程安全、空值支持、迭代器特性，前者适用于高并发场景，后者适用于单线程 / 低并发场景。
2026-03-05 23:42:03
354
原创 Java类生命周期7大阶段全解析
加载 - 验证 - 准备 - 解析 - 初始化 - 使用 - 卸载，其中初始化是触发业务逻辑的关键阶段，有明确的触发条件；类加载具有「懒加载」特性，JVM 按需加载类，且遵循双亲委派模型保证类唯一性；卸载条件严格，仅自定义类加载器加载的类可能被卸载，系统类通常不会卸载。
2026-03-05 10:32:29
439
原创 消息中间件篇八股文
1.在生产者发送消息这一端，你是怎么确保消息成功发送到 RabbitMQ 服务器的？在生产者端，我主要靠2.RabbitMQ 中的消息确认机制有哪几种？分别在什么阶段生效？
2026-03-05 10:32:00
875
原创 JVM分代回收
核心本质：分代回收是内存管理策略，基于对象生命周期差异分区，搭配最优 GC 算法；内存分区：堆 = 新生代 (Eden:From:To=8:1:1)+ 老年代，JDK8 使用元空间替代永久代；回收流程：新对象入 Eden → Minor GC 复制存活对象 → 满足条件晋升老年代 → 老年代触发 Major/Full GC；核心优势：分层回收、算法适配，兼顾效率与内存利用率；演进方向：传统分代在大堆场景存在瓶颈，G1/ZGC 等新一代收集器采用分区设计弱化固定分代。
2026-03-05 10:31:33
477
原创 JVM垃圾回收算法全解析
基础四大算法：标记 - 清除、复制、标记 - 整理、分代收集，分代收集是工业界标准方案；分区算法：新一代低延迟收集器的核心设计，解决大内存 GC 停顿问题；场景匹配：新生代用复制算法，老年代用标记 - 清除 / 标记 - 整理，是由对象存活特性决定的；核心矛盾：GC 算法的优化始终围绕停顿时间和吞吐量的平衡展开。
2026-03-04 21:19:16
401
原创 Spring事务传播机制7大类型详解
核心作用：事务传播机制定义了 “方法间调用时事务的交互规则”，解决多事务方法嵌套调用的事务边界问题。常用类型REQUIRED（默认，共用事务）、（独立事务）、SUPPORTS（查询用）是日常开发中最常使用的三种。关键注意NESTED依赖数据库保存点，而是完全独立的事务，二者不要混淆；传播机制仅在Spring 管理的事务方法间调用时生效（如非 public 方法、内部调用会失效）。
2026-03-04 21:18:41
633
原创 6大场景触发Java类初始化
触发类初始化的核心是主动使用类，共 6 种场景，其中前 5 种是面试高频考点，需重点记忆；区分 “编译期常量” 和 “普通静态变量”：前者不触发初始化，后者触发；子类初始化必然触发父类初始化，但父类静态成员的访问不会触发子类初始化。
2026-03-03 15:29:22
629
原创 微服务篇八股文
1. Spring Cloud 5 大组件有哪些？2. 服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？3. Nacos 与 Eureka 的区别？：均支持服务注册与发现，通过心跳检测实现服务健康检查。4. 项目中负载均衡如何实现的？项目中使用 Spring Cloud Ribbon 实现，Feign 客户端底层已集成 Ribbon，使用方式简洁：发起远程调用时，Ribbon 先从注册中心获取服务地址列表，再根据预设路由策略（常用轮询）选择服务实例调用。
2026-03-01 22:13:29
801
原创 MySQL八股文面试
② 开启 MySQL 慢查询日志：在系统配置文件中开启该功能，设置 SQL 执行超时阈值（如 long_query_time = 2 秒），超过阈值的 SQL 会被记录到日志文件中，从日志中查找慢查询 SQL。② 一致性（Consistency）：事务执行前后，数据的完整性约束保持一致，如 A 扣款 500 元，B 必须同步增加 500 元；③ 隔离性（Isolation）：多个并发事务之间相互独立，互不干扰，如 A 向 B 转账的过程中，不受其他转账事务的影响；
2026-02-26 19:11:02
419
1
原创 MySQL 锁的完整分类与详解
核心锁粒度：全局锁（整实例）> 表级锁（整表）> 行级锁（单行），粒度越小并发越高、开销越大；核心锁类型：共享锁（S）和排他锁（X）是基础，间隙锁 / 临键锁是 InnoDB 解决幻读的核心，MDL 锁保护表结构；引擎差异：MyISAM 仅支持表级锁，InnoDB 支持行级锁 + 表级锁，行锁是 InnoDB 保证事务 ACID 的核心。关键点：日常开发中，90% 的场景关注行级锁（X/S/ 临键锁）和MDL 锁即可，全局锁仅用于备份，表级锁尽量避免（会降低并发）。
2026-02-24 16:17:14
784
原创 JVM 中的强、软、弱、虚以及终结器引用的概念和区别
强引用是默认引用，只要存在就不会回收，是最常用的类型；软 / 弱引用用于缓存，区别在于回收时机（软引用内存不足才回收，弱引用 GC 就回收）；虚引用仅用于跟踪对象回收，无法获取对象；终结器引用是 JVM 内部实现 finalize () 的机制，不建议手动依赖。核心逻辑：引用类型决定了对象被 GC 回收的「门槛」，门槛从高到低依次是：强引用 > 软引用 > 弱引用 > 虚引用。
2026-02-07 20:47:22
729
原创 Spring @Transactional 事务失效7大坑点，你踩过几个？
Spring 事务失效的核心根源是代理对象未被正确触发或配置不符合 Spring 事务规则，其中 “内部调用” 和 “异常被吞” 是最高频坑点。开发时只需严格遵循上述 7 条规则，90% 的事务问题可提前规避；排查时优先开启 debug 日志，结合自检清单，可快速定位问题根源。
2026-02-07 15:05:33
787
原创 支付防重复下单｜5 种幂等性设计方案（从初级到架构级）
同一个请求无论执行多少次，最终结果完全一致。典型场景：用户支付时网络卡顿重复点击按钮，后台接收多个请求，仅扣一次钱、生成一个订单。幂等性是分布式系统的基本功，并非简单加锁即可解决；实际开发中需结合业务场景组合方案保证请求处理的原子性，杜绝重复执行带来的脏数据。
2026-02-06 22:06:18
1099
原创 JVM类加载机制与双亲委派
双亲委派机制是 JVM 类加载的默认规则：当一个类加载器收到类加载请求时，不会自己先尝试加载，而是将请求向上委托给父加载器，递归向上直到顶层启动类加载器；只有当父加载器无法加载该类时，子加载器才会尝试自己加载。继承抽象类；重写方法，破坏默认的双亲委派递归逻辑；重写方法，实现自定义的类字节码读取逻辑。四大类加载器：Bootstrap（顶层、C 实现）→ Extension → Application → 自定义加载器，层级为组合关系而非继承；双亲委派机制：向上委托、向下加载，核心价值是。
2026-02-06 15:19:32
862
原创 JDK1.8 HashMap核心优化全解析
核心升级：新增红黑树解决长链表性能问题，尾插法解决并发死循环问题，简化哈希算法提升效率；性能提升：高冲突场景下，JDK 1.8 的 HashMap 性能远优于 1.7；设计原则：所有优化都围绕性能、稳定性、代码简洁性展开，是哈希表结构的经典工程优化；注意事项：结构升级不改变线程不安全特性，并发场景不可使用。
2026-02-05 18:31:03
815
原创 HashMap扩容机制（jdk1.7与jdk1.8的不同）
判断容量上限：若已达最大容量，修改阈值并直接返回，不扩容；计算新容量 / 新阈值：容量翻倍，阈值同步翻倍；创建新数组：根据新容量初始化哈希桶数组；遍历旧数组：逐个处理每个桶位的节点；分场景迁移节点单节点：直接计算新索引赋值；红黑树：执行树节点拆分与迁移；链表：拆分为高低位链表，批量迁移，保持顺序；替换引用：将table指向新数组，旧数组等待垃圾回收。扩容核心目标：动态调整数组容量，降低哈希冲突概率，维持 HashMap 高性能；核心规则：容量翻倍增长，数据迁移采用高低位链表拆分。
2026-02-05 18:29:13
1084
原创 Java各个集合框架之间的区别
List侧重有序可重复、索引访问，ArrayList 适合读操作，LinkedList 适合写操作；Set侧重元素去重，HashSet 高性能、LinkedHashSet 保序、TreeSet 排序；Map侧重键值对存储，HashMap 通用高性能，LinkedHashMap 保序，TreeMap 排序；所有非 JUC 集合均非线程安全，高并发场景优先使用包下的线程安全集合。
2026-02-04 21:18:53
827
原创 HashMap的put方法核心流程与优化解析
JDK 8 相比之前的版本主要做了两个优化：一是链表插入从头插改成了尾插，避免了并发下的死链问题；二是链表长度超过 8 时转为红黑树，把链表的 O (n) 查询复杂度降到了 O (log n)。，将数组容量翻倍，并重新哈希所有元素。
2026-02-04 17:52:45
807
原创 ArrayList动态扩容机制
ArrayList 底层是动态数组，扩容本质是创建新数组并复制原数组元素，默认扩容为原容量的1.5 倍（通过位运算实现）；无参构造的 ArrayList 初始容量为 0，第一次添加元素时扩容到 10，后续按 1.5 倍扩容；扩容的性能瓶颈是数组复制，提前指定初始容量可大幅提升 ArrayList 的性能。
2026-02-02 18:13:00
1342
原创 RabbitMQ交换机与队列核心类型解析
交换机核心：Direct（精准）、Fanout（广播）、Topic（通配符）是主流，Headers 极少用；队列核心：仲裁队列（强一致、高可用）是核心业务首选，镜像队列逐步被替代，死信队列用于异常消息处理；选型逻辑：交换机看 “路由需求”，队列看 “高可用 / 一致性需求”。
2026-01-31 19:01:50
883
原创 花了7K买的在某知名教育平台买的项目，要哭死！！！
花生二手车交易平台是一个由大学生独立开发的全栈项目，涵盖前后端开发，聚焦二手车交易全流程。后端采用SpringBoot+MyBatis+Redis等技术，实现高并发订单处理、实时通信及AI智能客服；前端基于Vue3+ElementPlus构建多角色交互界面。项目亮点包括RabbitMQ异步解耦提升订单处理性能、WebSocket实时消息、AI智能估价与文案优化，以及多角色权限管理。提供完整开源代码及开发心得，适合作为学习或二次开发参考。
2026-01-29 21:21:40
1043
原创 SpringBoot自动装配核心步骤
SpringBoot 的自动装配核心是整体来说，自动装配的本质就是 **“注解触发→扫描配置→条件过滤→自动注册 Bean”**，核心是通过约定的配置文件和条件注解，实现了 “引入依赖即生效，自定义配置可覆盖” 的特性。
2026-01-28 20:37:29
1099
原创 Redis面试八股文
1. 什么是缓存穿透？怎么解决？缓存穿透是指查询一个一定不存在的数据，由于存储层查不到数据因此不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。解决方案通常会用来解决。2. 你能介绍一下布隆过滤器吗？布隆过滤器主要是用于检索一个元素是否在一个集合中，项目中使用的是实现的布隆过滤器。：先初始化一个比较大的二进制数组，初始值都是 0；当一个 key 到来后，经过。
2026-01-26 13:57:44
1043
原创 超卖问题终极解决方案大揭秘
超卖问题的解决本质是保证库存扣减的原子性，不同方案的核心差异是原子性的实现载体（数据库 SQL / 数据库锁 / Redis 原子操作 + 分布式锁 / Redis+MQ）；数据库与缓存的一致性随缓存层的引入发生变化，无缓存方案天然强一致，引入 Redis 的分布式方案仅能保证最终一致，且需遵循 “Redis 预扣减先行、数据库为真相源、补偿机制兜底” 的原则；架构设计需在一致性和性能之间做权衡，强一致方案性能较低，最终一致方案性能更高，无需为了极致一致性牺牲业务所需的并发性能；
2026-01-26 11:43:25
1547
1
原创 Redis事务面试精要：核心机制与实战解析
答：Redis 事务是把多个命令打包成队列，通过MULTI开启、EXEC串行化执行的机制，实现分三步：1、可选WATCH监控键做乐观锁；2、MULTI开启后命令入队，返回QUEUED；3、EXEC执行所有入队命令，DISCARD可放弃事务。核心命令就是，执行中不会被其他客户端打断。
2026-01-25 16:28:27
796
原创 Redis五大核心数据类型解析
Redis 五大核心类型：String（字符串 / 计数器）、Hash（对象）、List（队列）、Set（去重 / 集合运算）、Zset（排序 / 排行榜）；面试答题核心：先讲类型，再讲核心特性，最后结合场景（“是什么 - 能做什么 - 用在哪”）；底层小技巧：String（int/embstr/raw）、List（快速链表）、Hash/Set（哈希表）、Zset（跳表 + 哈希表），提一句能加分。
2026-01-25 16:28:16
667
原创 MySQL MVCC 深度解析（从基础到 RC/RR 级别实现）
RC 和 RR 级别均基于隐藏字段 + undo log 版本链 + ReadView实现 MVCC，核心差异仅在于ReadView 的生成时机特性RC（读已提交）RR（可重复读）ReadView 生成时机每次快照读（SELECT）重新生成一个新的仅第一次快照读生成，后续复用同一个同一事务多次读结果可能不同（能读到其他事务提交的修改）一定相同（无法读到其他事务提交的修改）幻读问题存在（仅解决了不可重复读）基本解决（MVCC + 间隙锁，InnoDB 的 RR 级别无幻读）并发性能。
2026-01-24 18:43:00
1171
原创 MySQL 核心日志：redo log、undo log 与 MVCC 深度讲解
核心：保障事务持久性，解决缓冲池异步刷盘带来的崩溃数据丢失问题；性能：将「随机磁盘写」（修改数据页的随机刷盘）转化为「顺序磁盘写」（redo log 是环形文件，顺序写入），大幅提升 MySQL 写入性能；恢复：数据库崩溃后，通过 redo log 重放实现数据恢复，无需重新执行所有事务。redo log物理日志、循环写、遵循 WAL，核心保障事务持久性，解决缓冲池异步刷盘的崩溃恢复问题，将随机写转为顺序写提升性能，其刷盘策略决定了持久性与性能的权衡；undo log逻辑日志、非循环写、可回收。
2026-01-24 18:42:49
1504
原创 Redis主从同步全解析：全量与增量流程详解
全量同步：初次连接或数据差异大时触发，通过 RDB 快照 + 缓存命令实现全量数据复制。增量同步：日常同步和断连重连时触发，仅同步主节点新的写命令，效率更高。核心依赖replid识别数据集、offset跟踪同步进度、支持增量同步。
2026-01-23 10:27:32
1609
1
原创 缓存击穿中逻辑过期和单纯互斥锁区别
逻辑过期加互斥锁，是为了防止缓存过期后大量请求同时触发缓存更新，避免数据库被异步更新请求压垮；和单纯互斥锁的核心区别：逻辑过期方案不删除缓存、返回旧数据、无请求阻塞，而单纯互斥锁会删除缓存、等待锁释放、返回最新数据；选型原则：对实时性要求低、追求高并发高可用选 “逻辑过期 + 锁”，对实时性要求高选 “单纯互斥锁”。通俗解释二者区别。
2026-01-23 10:26:58
1308
原创 Redis持久化：RDB与AOF的终极对比
Redis 持久化核心是 RDB（快照）和 AOF（日志），混合持久化是生产首选；RDB 快但丢数据多，适合备份；AOF 安全但恢复慢，适合核心业务；优惠券秒杀场景推荐「混合持久化 + appendfsync everysec」，平衡性能和数据安全性；核心区别：RDB 记录「数据结果」，AOF 记录「数据修改过程」。
2026-01-22 14:20:03
934
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人