初心未改

MySQL选择B+树作为索引结构，主要因其能有效减少磁盘I/O次数，特别适合大规模数据的增删改查和范围查询。相比哈希表无法支持范围查询、二叉树I/O效率低，B+树具有多路搜索、树高低、叶子节点形成有序链表等特点，使查询性能稳定且高效。B+树节点大小匹配磁盘页，利用预读机制，3-4次I/O即可定位亿级数据，同时支持高效的全表扫描和范围查询，是关系型数据库索引的最佳选择。

本文系统化地介绍了数据库性能优化的三个阶段。第一阶段聚焦低成本高收益方案：精细化索引优化、SQL语句优化和数据库配置调优；第二阶段引入应用架构优化：使用缓存、读写分离和消息队列等手段；第三阶段涉及高级架构方案：垂直分库和水平分片等数据拆分策略。特别针对动态数据查询场景，建议采用Elasticsearch等专用搜索系统或物化视图方案。整体优化应遵循"诊断先行、由浅入深"原则，从简单索引优化逐步过渡到复杂架构改造，最终实现性能提升。

摘要：Redis缓存同步链路的核心在于实现数据库与缓存的数据一致性。常见方案包括：1）基于事件驱动的同步（如监听MySQL Binlog），解耦性好但架构复杂；2）消息队列异步同步，平衡性能与解耦；3）同步双写，简单直接但耦合度高。最佳实践建议采用Cache Aside模式，优先删除而非更新缓存，并设置重试机制和合理TTL。选择方案需权衡一致性要求、系统规模和团队能力，中大型系统推荐事件驱动方案，小型系统可考虑同步双写但需完善错误处理。

Java锁升级机制是JVM对synchronized关键字的优化策略，通过动态调整锁状态来平衡性能与线程安全。主要包括四个阶段：无锁状态（01标志）、偏向锁（记录线程ID，适用于单线程场景）、轻量级锁（CAS自旋，适合低竞争）和重量级锁（内核态互斥，处理高竞争）。该机制采用单向升级策略，根据竞争激烈程度自动切换，在保证线程安全的同时最小化性能开销。自JDK1.6引入后显著提升了synchronized性能，使其在多场景下接近ReentrantLock的效率，而开发者无需手动干预这一透明优化过程。

Java线程同步工具synchronized和ReentrantLock的核心区别在于：synchronized是JVM级别的隐式锁，自动释放但灵活性差；ReentrantLock是API级别的显式锁，需手动管理但功能更强。ReentrantLock支持可中断锁、超时获取、公平锁、多条件变量等高级特性。synchronized在JDK1.6+后性能优化良好，简单场景优先使用；复杂场景如需要精确控制时，才考虑使用ReentrantLock。选择应基于需求复杂度，多数情况下synchronized更安全简洁。

数据倾斜是分库分表实践中常见的问题，导致部分节点负载过高而影响系统性能。主要原因包括分片键选择不当、哈希函数不合理、业务热点等。解决方案分为治本和治标：调整分片策略（更换分片键、使用复合键或优化哈希算法）和应对业务热点（二级索引、读写分离、多级缓存）。预防措施包括设计阶段充分调研、使用成熟中间件和加强监控。核心思路是确保数据均匀分布或系统能处理不均匀数据，需要根据业务场景选择合适方案。

分布式锁加锁失败后的等待策略主要有两种：客户端轮询和服务端通知。客户端轮询包括简单固定间隔和带随机抖动的指数退避法，后者通过指数增长延迟和随机抖动避免"羊群效应"，是Redis等简单锁的推荐方案。服务端通知如ZooKeeper的Watch机制能实时响应锁释放，效率最高但实现复杂。生产环境通常结合两种策略：先快速重试，失败后转为指数退避，并设置总超时。选择策略需权衡实现复杂度、系统压力和应用场景需求。

摘要：MySQL InnoDB的行级锁实际上是锁定索引项而非数据行本身。通过聚簇索引操作时直接锁定索引记录，通过二级索引则先在二级索引加锁再回表锁定主键索引。若查询未使用索引，会导致全表扫描并升级为表锁，严重影响并发性能。行锁分为记录锁、间隙锁和临键锁三种类型。关键实践建议包括确保查询有效使用索引、优先使用主键/唯一索引、控制事务时长以及理解不同隔离级别的锁策略差异。良好的索引设计是保证行级锁效用的前提条件。

摘要：在分布式系统中，RabbitMQ等消息队列可能因网络抖动、故障导致消息重复投递。实现消息幂等性需由消费者完成，常见方案包括：1）业务逻辑天然幂等（如查询）；2）唯一键控制（最推荐），通过数据库唯一约束防止重复；3）状态机控制（适用于订单等有状态业务）；4）Redis缓存去重（高性能但可靠性较低）。建议优先采用唯一键方案，可结合多种方法，消息设计需包含全局唯一ID，并养成"先查询后处理"的习惯。本质上，消息队列提供"至少一次"投递保证，而"恰好一次&qu

本文介绍了一个高效通用的Java线程池管理工具类ThreadPoolManager，主要特点包括：1）支持IO/CPU密集型任务自动配置；2）提供Builder模式配置线程池参数；3）内置监控指标采集功能；4）实现优雅关闭和智能拒绝策略；5）支持任务包装器和动态参数调整。该工具类采用最佳实践设计，包含线程池指标监控、异常处理、资源清理等机制，并提供了与SpringBoot集成的示例。通过自动计算线程数、有界队列管理和智能重试等特性，有效提升了线程池的安全性和健壮性，适用于各种Java应用场景。

Java线程池的核心在于线程复用和任务队列管理，通过合理配置核心线程数、最大线程数、队列容量和拒绝策略来优化性能。关键点包括：区分CPU密集型和IO密集型任务设置线程数、使用有界队列防止OOM、自定义线程工厂便于监控、正确处理任务异常。需特别注意避免使用Executors默认工厂方法，而应手动创建ThreadPoolExecutor，并关注线程泄漏、死锁风险等问题。最佳实践包括压力测试调优、实施监控告警以及实现优雅关闭机制。

摘要：时间复杂度衡量任务规模(n)扩大时所需操作步骤的增长趋势。O(1)表示固定步骤(如数组直接访问)；O(n)是线性增长(如遍历查找)；O(logn)高效对数增长(如二分查找)；O(n²)为平方级增长(如嵌套循环)。关键关注最坏情况下的增长趋势，忽略常数影响。不同复杂度在数据量小时差异不大，但大数据时差距显著：O(n²)可能极慢，而O(logn)仍高效。理解复杂度有助于选择合适算法(如快速排序优于冒泡排序)和数据结构(ArrayList随机访问O(1)优于LinkedList的O(n))，对处理海量数据尤

JDK1.8中HashMap引入红黑树结构，主要解决哈希冲突严重时链表查询性能退化问题。当链表长度超过8且容量≥64时转换为红黑树，将最坏时间复杂度从O(n)降至O(logn)。设置6作为退化阈值避免频繁转换。这种设计在空间开销与性能保障间取得平衡：基于泊松分布，正常使用很少触发树化，仅在哈希分布异常时提供性能保障。红黑树的引入显著提升了HashMap在极端情况下的健壮性，是JDK1.8的重要优化。

Java面试相关技术点，Java面试准备，面试攻坚