Java并发编程与JVM调优核心知识点解析

1. Java并发编程核心知识点解析

1.1 锁机制深度剖析

在Java并发编程中，锁机制是最基础也是最重要的概念之一。根据不同的应用场景和性能需求，我们可以选择不同类型的锁来实现线程安全。

1.1.1 悲观锁的实现与应用场景

悲观锁的核心思想是"先加锁再操作"，它假设并发冲突一定会发生。在Java中，synchronized关键字和ReentrantLock都是典型的悲观锁实现。

java复制// synchronized示例
public synchronized void transfer(Account from, Account to, int amount) {
    if (from.getBalance() >= amount) {
        from.debit(amount);
        to.credit(amount);
    }
}

// ReentrantLock示例
private final Lock lock = new ReentrantLock();
public void transfer(Account from, Account to, int amount) {
    lock.lock();
    try {
        if (from.getBalance() >= amount) {
            from.debit(amount);
            to.credit(amount);
        }
    } finally {
        lock.unlock();
    }
}

关键细节与最佳实践：

1. 锁粒度控制：应该尽量缩小锁的范围，只锁定必要的代码块
2. 避免嵌套锁：多个锁的嵌套容易导致死锁
3. 锁与事务配合：数据库事务中，应该先提交事务再释放锁，避免其他线程看到中间状态
4. 性能考量：悲观锁适合写多读少的场景，特别是数据竞争激烈的环境

1.1.2 乐观锁的实现与适用场景

乐观锁采取"先操作再验证"的策略，它假设并发冲突很少发生。Java中的原子类和数据库的version字段都是乐观锁的典型实现。

java复制// CAS操作示例
AtomicInteger counter = new AtomicInteger(0);
public void safeIncrement() {
    int oldValue, newValue;
    do {
        oldValue = counter.get();
        newValue = oldValue + 1;
    } while (!counter.compareAndSet(oldValue, newValue));
}

// 数据库version字段示例
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 100 AND version = 5;

关键细节与最佳实践：

1. 版本号机制：每次更新都需要检查并更新版本号
2. 重试策略：冲突时需要决定重试次数和回退策略
3. 适用场景：读多写少，冲突概率低的场景
4. ABA问题：CAS操作需要注意ABA问题，可以通过添加版本号或时间戳解决

1.1.3 分布式锁的实现方案

在分布式系统中，我们需要跨JVM的锁机制。常见的实现方式有基于Redis和ZooKeeper的方案。

Redis分布式锁实现要点：

java复制// 获取锁
SET lock_key unique_value NX PX 30000

// 释放锁
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

关键问题与解决方案：

1. 锁误删问题：通过设置唯一标识（如UUID）避免误删其他线程的锁
2. 锁续期问题：通过守护线程定期续期防止业务未完成锁已过期
3. 集群故障转移：RedLock算法可以一定程度解决但仍有争议
4. 性能考量：Redis实现的分布式锁性能较高但可靠性略低于ZooKeeper

ZooKeeper分布式锁实现要点：

1. 顺序临时节点：利用ZK的顺序临时节点特性实现锁
2. Watch机制：通过监听前一个节点实现锁等待
3. 可靠性：ZK的强一致性保证了锁的可靠性
4. 性能：相比Redis性能略低但更可靠

1.2 死锁分析与预防

死锁是多线程编程中最棘手的问题之一，理解其产生条件和预防方法至关重要。

1.2.1 死锁产生的四个必要条件

1. 互斥条件：资源一次只能被一个线程占用
2. 占有且等待：线程持有资源并等待其他资源
3. 不可抢占：资源只能由持有者主动释放
4. 循环等待：多个线程形成资源等待环

1.2.2 死锁预防策略

资源有序分配法：

java复制// 定义资源类型顺序
public enum ResourceType {
    PRINTER, SCANNER, PLOTTER;
}

// 按照固定顺序获取资源
public void process() {
    Resource printer = getResource(ResourceType.PRINTER);
    Resource scanner = getResource(ResourceType.SCANNER);
    // 业务逻辑
    release(scanner);
    release(printer);
}

其他预防方法：

1. 超时放弃：获取锁时设置超时，超时后释放已有锁并重试
2. 银行家算法：系统预判分配是否安全再决定分配
3. 资源预分配：一次性申请所有需要的资源

1.2.3 死锁检测与恢复

1. 资源分配图算法：检测图中是否存在环
2. 线程转储分析：通过jstack分析线程状态
3. 恢复策略：选择牺牲者强制释放资源

1.3 ConcurrentHashMap深度解析

ConcurrentHashMap是Java并发包中最重要且最复杂的集合类之一，它的实现经历了多次优化。

1.3.1 JDK7实现原理

JDK7中采用分段锁设计，将数据分为多个Segment，每个Segment独立加锁。

java复制// JDK7的put方法核心逻辑
public V put(K key, V value) {
    Segment<K,V> s;
    // 计算segment索引
    int hash = hash(key);
    int j = (hash >>> segmentShift) & segmentMask;
    // 获取或创建segment
    if ((s = (Segment<K,V>)UNSAFE.getObject(segments, j)) == null)
        s = ensureSegment(j);
    // 调用segment的put方法
    return s.put(key, hash, value, false);
}

分段锁特点：

1. 并发度等于Segment数量（默认16）
2. 不同Segment的操作可以并行
3. 同一Segment的操作需要竞争锁

1.3.2 JDK8实现原理

JDK8进行了重大改进，采用CAS+synchronized实现更细粒度的锁控制。

java复制// JDK8的putVal方法核心逻辑
final V putVal(K key, V value, boolean onlyIfAbsent) {
    // 计算hash
    int hash = spread(key.hashCode());
    // 循环直到插入成功
    for (Node<K,V>[] tab = table;;) {
        Node<K,V> f; int n, i, fh;
        // 表为空则初始化
        if (tab == null || (n = tab.length) == 0)
            tab = initTable();
        // 计算桶位置，如果为空则CAS插入
        else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
            if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null)))
                break;
        }
        // 如果正在扩容则帮助扩容
        else if ((fh = f.hash) == MOVED)
            tab = helpTransfer(tab, f);
        else {
            // 对桶加锁处理
            synchronized (f) {
                // 链表或红黑树插入逻辑
                // ...
            }
        }
    }
    // 更新size计数
    addCount(1L, binCount);
    return null;
}

JDK8改进点：

1. 取消分段锁，采用更细粒度的桶级别锁
2. 使用CAS实现无锁化操作
3. 引入红黑树解决哈希冲突性能问题
4. 扩容时支持并发迁移

1.3.3 关键性能考量

1. 并发度：理论上最大并发度等于桶的数量
2. 扩容机制：支持多线程协同扩容，减少性能波动
3. 统计计数：采用分段计数避免CAS竞争
4. 迭代器一致性：弱一致性迭代器反映创建时的状态

1.4 线程池深度解析

线程池是Java并发编程的核心组件，合理使用线程池可以显著提升系统性能。

1.4.1 线程池核心参数详解

java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
    corePoolSize,    // 核心线程数
    maximumPoolSize, // 最大线程数
    keepAliveTime,   // 空闲线程存活时间
    unit,            // 时间单位
    workQueue,       // 工作队列
    threadFactory,   // 线程工厂
    handler          // 拒绝策略
);

七大核心参数：

1. corePoolSize：核心线程数，即使空闲也不会被回收
2. maximumPoolSize：最大线程数=核心线程+救急线程
3. keepAliveTime：救急线程空闲存活时间
4. unit：存活时间单位
5. workQueue：任务队列，常见实现有：
   • ArrayBlockingQueue：有界数组队列
   • LinkedBlockingQueue：无界链表队列
   • SynchronousQueue：不存储元素的队列
   • PriorityBlockingQueue：优先级队列
6. threadFactory：线程创建工厂，可定制线程属性
7. handler：拒绝策略，包括：
   • AbortPolicy：直接抛出异常（默认）
   • CallerRunsPolicy：由调用者线程执行
   • DiscardPolicy：静默丢弃
   • DiscardOldestPolicy：丢弃队列中最老的任务

1.4.2 线程池工作流程

1. 提交任务后，如果核心线程未满，则创建新线程执行
2. 如果核心线程已满，任务进入工作队列
3. 如果队列已满且线程数未达最大值，创建救急线程
4. 如果线程数已达最大值，执行拒绝策略

流程图解：

code复制任务提交 → 核心线程是否满？ → 否 → 创建核心线程执行
            ↓是
        队列是否满？ → 否 → 加入队列等待
            ↓是
        线程数是否达最大？ → 否 → 创建救急线程执行
            ↓是
        执行拒绝策略

1.4.3 线程池类型与适用场景

1. FixedThreadPool：

   • 特点：固定大小，无界队列
   • 适用：已知并发量且任务执行时间较长的场景

2. SingleThreadExecutor：

   • 特点：单线程，无界队列
   • 适用：需要顺序执行任务的场景

3. CachedThreadPool：

   • 特点：弹性线程数，同步队列
   • 适用：短生命周期的异步任务

4. ScheduledThreadPool：

   • 特点：支持定时/周期性任务
   • 适用：需要定时执行或延迟执行的场景

1.4.4 线程池大小配置策略

CPU密集型任务：

code复制线程数 = CPU核心数 + 1

理由：减少线程上下文切换，最大化CPU利用率

IO密集型任务：

code复制线程数 = CPU核心数 * (1 + 平均等待时间/平均计算时间)

经验值通常为CPU核心数的2-3倍

混合型任务：
可以将任务拆分为CPU密集和IO密集两部分，分别使用不同的线程池

动态调整策略：

1. 监控线程池状态（队列大小、活跃线程数等）
2. 根据负载情况动态调整核心和最大线程数
3. 考虑使用ThreadPoolExecutor的setCorePoolSize方法

1.4.5 线程池使用注意事项

1. 避免任务堆积：合理设置队列容量，防止OOM
2. 合理处理异常：任务内部捕获异常或实现UncaughtExceptionHandler
3. 资源清理：对于需要清理的资源，实现afterExecute钩子
4. 避免死锁：注意任务间的依赖关系
5. 监控与调优：记录关键指标如任务执行时间、排队时间等

1.5 ThreadLocal原理与内存泄漏防范

ThreadLocal提供了线程局部变量，每个线程都有自己独立的变量副本。

1.5.1 核心实现原理

java复制public class ThreadLocal<T> {
    // 每个Thread对象内部都有一个ThreadLocalMap
    static class ThreadLocalMap {
        // Entry继承自WeakReference，key是弱引用
        static class Entry extends WeakReference<ThreadLocal<?>> {
            Object value;
            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        // ... map实现
    }
    
    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = t.threadLocals;
        if (map != null)
            map.set(this, value);
        else
            t.threadLocals = new ThreadLocalMap(this, value);
    }
}

关键点：

1. 每个Thread维护一个ThreadLocalMap
2. Map的key是ThreadLocal实例，value是存储的值
3. Entry继承自WeakReference，key是弱引用

1.5.2 内存泄漏问题分析

泄漏原因：

1. key是弱引用，GC时会被回收
2. value是强引用，不会被自动回收
3. 如果Thread长期存活，会导致value无法回收

解决方案：

1. 使用完ThreadLocal后调用remove()方法
2. 将ThreadLocal声明为static final，避免频繁创建
3. 使用自定义的ThreadLocal子类覆盖initialValue()

1.5.3 应用场景

1. 上下文传递：如Spring的事务管理
2. 线程安全工具类：如SimpleDateFormat
3. 跨方法参数传递：避免方法参数层层传递
4. 性能优化：线程局部缓存

2. JVM虚拟机深度解析

2.1 JVM内存模型详解

2.1.1 运行时数据区组成

1. 程序计数器：

   • 线程私有
   • 记录当前线程执行的字节码指令地址
   • 唯一不会OOM的区域

2. Java虚拟机栈：

   • 线程私有
   • 存储栈帧（局部变量表、操作数栈、动态链接、方法出口）
   • 可能抛出StackOverflowError和OutOfMemoryError

3. 本地方法栈：

   • 线程私有
   • 为Native方法服务
   • 同样可能抛出StackOverflowError和OutOfMemoryError

4. Java堆：

   • 线程共享
   • 存储对象实例和数组
   • GC主要区域
   • 可能抛出OutOfMemoryError

5. 方法区（元空间）：

   • 线程共享
   • 存储类信息、常量、静态变量等
   • JDK8后使用本地内存
   • 可能抛出OutOfMemoryError

2.1.2 堆内存结构

新生代（Young Generation）：

• Eden区：对象首次分配区域
• Survivor区（From/To）：Minor GC后存活对象转移区域
• 默认比例Eden:From:To=8:1:1

老年代（Old Generation）：

• 长期存活的对象晋升到此
• Major GC/Full GC主要清理此区域

对象分配与晋升规则：

1. 新对象优先在Eden区分配
2. Minor GC后存活对象进入Survivor区
3. 年龄计数器达到阈值（默认15）晋升老年代
4. 大对象直接进入老年代
5. Survivor区相同年龄对象大小超过一半时，大于等于该年龄的对象直接晋升

2.1.3 直接内存

• 不属于JVM运行时数据区
• 通过Native函数库直接分配堆外内存
• 常见于NIO的ByteBuffer.allocateDirect()
• 不受GC管理，需要手动释放
• 可能抛出OutOfMemoryError

2.2 垃圾回收机制

2.2.1 对象存活判断

1. 引用计数法：

   • 简单但无法解决循环引用问题
   • Python使用，Java未采用

2. 可达性分析算法：

   • 从GC Roots对象开始搜索引用链
   • 不可达对象标记为可回收
   • GC Roots包括：
     • 虚拟机栈中引用的对象
     • 方法区中类静态属性引用的对象
     • 方法区中常量引用的对象
     • 本地方法栈中JNI引用的对象

2.2.2 垃圾回收算法

1. 标记-清除算法：

   • 标记所有需要回收的对象
   • 统一回收被标记对象
   • 缺点：内存碎片化

2. 标记-整理算法：

   • 标记过程同标记-清除
   • 存活对象向一端移动
   • 清理边界外内存
   • 优点：减少碎片
   • 缺点：移动成本高

3. 复制算法：

   • 内存分为大小相同的两块
   • 每次使用一块，存活对象复制到另一块
   • 优点：简单高效
   • 缺点：内存利用率低
   • 适用于新生代（Eden和Survivor区）

4. 分代收集算法：

   • 结合多种算法
   • 新生代使用复制算法
   • 老年代使用标记-清除或标记-整理

2.2.3 垃圾收集器

1. Serial收集器：

   • 单线程
   • 新生代复制算法，老年代标记-整理
   • Client模式默认

2. ParNew收集器：

   • Serial的多线程版本
   • 新生代并行，老年代串行
   • Server模式首选新生代收集器

3. Parallel Scavenge收集器：

   • 吞吐量优先
   • 新生代并行，老年代串行
   • 适合后台运算

4. CMS收集器：

   • 低延迟
   • 标记-清除算法
   • 过程：
     • 初始标记（STW）
     • 并发标记
     • 重新标记（STW）
     • 并发清除
   • 缺点：内存碎片，CPU敏感

5. G1收集器：

   • 面向服务端
   • 将堆划分为多个Region
   • 可预测停顿时间
   • 过程：
     • 初始标记（STW）
     • 并发标记
     • 最终标记（STW）
     • 筛选回收（STW）
   • 优点：空间整合，可预测停顿

6. ZGC收集器：

   • JDK11引入
   • 低延迟（<10ms）
   • 基于Region
   • 并发标记-整理
   • 支持TB级堆

2.3 类加载机制

2.3.1 类加载过程

1. 加载：

   • 获取类的二进制流
   • 转换为方法区数据结构
   • 生成Class对象

2. 验证：

   • 文件格式验证
   • 元数据验证
   • 字节码验证
   • 符号引用验证

3. 准备：

   • 为静态变量分配内存
   • 设置初始值（零值）

4. 解析：

   • 符号引用转直接引用

5. 初始化：

   • 执行类构造器()
   • 静态变量赋值
   • 静态代码块执行

2.3.2 类加载器

1. 启动类加载器（Bootstrap）：

   • C++实现
   • 加载<JAVA_HOME>/lib目录

2. 扩展类加载器（Extension）：

   • Java实现
   • 加载<JAVA_HOME>/lib/ext目录

3. 应用程序类加载器（Application）：

   • 加载ClassPath指定内容
   • 默认类加载器

4. 自定义类加载器：

   • 继承ClassLoader
   • 重写findClass()

2.3.3 双亲委派模型

工作流程：

1. 类加载请求先交给父类加载器
2. 父类加载器无法完成时子类才尝试加载
3. 所有加载器都无法加载时抛出ClassNotFoundException

优势：

1. 避免重复加载
2. 防止核心API被篡改
3. 保证类的一致性

破坏场景：

1. SPI机制（如JDBC）
2. OSGi模块化
3. 热部署

2.4 JVM调优实战

2.4.1 常用JVM参数

堆内存设置：

code复制-Xms512m  // 初始堆大小
-Xmx2g    // 最大堆大小
-Xmn256m  // 新生代大小
-XX:NewRatio=2  // 老年代/新生代比例
-XX:SurvivorRatio=8  // Eden/Survivor比例

GC相关：

code复制-XX:+UseG1GC  // 使用G1收集器
-XX:MaxGCPauseMillis=200  // 目标停顿时间
-XX:InitiatingHeapOccupancyPercent=45  // 触发并发标记的堆占用率

元空间：

code复制-XX:MetaspaceSize=128m  
-XX:MaxMetaspaceSize=256m

OOM处理：

code复制-XX:+HeapDumpOnOutOfMemoryError  
-XX:HeapDumpPath=/path/to/dump.hprof

2.4.2 调优工具

1. 命令行工具：

   • jps：查看Java进程
   • jstat：监控GC和内存
   • jmap：堆内存分析
   • jstack：线程堆栈分析
   • jinfo：查看和修改JVM参数

2. 可视化工具：

   • JConsole：基础监控
   • VisualVM：功能全面
   • MAT：内存分析
   • JProfiler：商业分析工具

2.4.3 常见问题排查

CPU飙高排查：

1. top -Hp [pid] 定位高CPU线程
2. printf "%x\n" [tid] 转换线程ID为16进制
3. jstack [pid] | grep [nid] 查看线程堆栈

内存泄漏排查：

1. jmap -histo:live [pid] 查看对象分布
2. jmap -dump:format=b,file=heap.hprof [pid] 生成堆转储
3. MAT分析堆转储文件

死锁排查：

1. jstack [pid] 查看线程堆栈
2. 搜索"deadlock"关键字
3. 分析锁持有和等待关系

3. MySQL数据库深度解析

3.1 存储引擎比较与选择

3.1.1 InnoDB vs MyISAM

核心差异对比表：

适用场景选择：

• InnoDB：需要事务、高并发写、数据一致性要求高的场景
• MyISAM：读密集、不需要事务、对COUNT(*)操作频繁的场景

3.1.2 其他存储引擎

1. MEMORY：

   • 数据存储在内存中
   • 表级锁
   • 不支持TEXT/BLOB类型
   • 服务重启数据丢失

2. ARCHIVE：

   • 高压缩比
   • 只支持INSERT和SELECT
   • 适合日志和归档数据

3. NDB：

   • MySQL集群专用
   • 数据分布在多个节点
   • 高可用性

3.2 事务与隔离级别

3.2.1 ACID特性实现原理

1. 原子性(Atomicity)：

   • 通过undo log实现
   • 记录事务开始前的数据状态
   • 回滚时恢复原始数据

2. 一致性(Consistency)：

   • 通过其他三个特性保证
   • 应用层也需要保证业务一致性

3. 隔离性(Isolation)：

   • 通过锁和MVCC实现
   • 不同隔离级别实现方式不同

4. 持久性(Durability)：

   • 通过redo log实现
   • 先写日志再写数据
   • 崩溃恢复时重做已提交事务

3.2.2 隔离级别与问题

InnoDB的RR级别如何避免幻读：

1. 快照读：通过MVCC多版本控制
2. 当前读：通过间隙锁(Gap Lock)锁定范围

3.2.3 MVCC实现原理

多版本并发控制(Multi-Version Concurrency Control)是InnoDB实现非锁定读的关键。

核心组件：

1. 隐藏字段：

   • DB_TRX_ID：最近修改事务ID
   • DB_ROLL_PTR：回滚指针
   • DB_ROW_ID：隐藏自增ID

2. undo log：

   • 存储历史版本数据
   • 形成版本链

3. ReadView：

   • m_ids：活跃事务列表
   • min_trx_id：最小活跃事务ID
   • max_trx_id：预分配最大事务ID
   • creator_trx_id：创建ReadView的事务ID

可见性判断规则：

1. trx_id == creator_trx_id：当前事务修改，可见
2. trx_id < min_trx_id：已提交，可见
3. trx_id >= max_trx_id：将来事务，不可见
4. min_trx_id <= trx_id < max_trx_id：
   • 在m_ids中：未提交，不可见
   • 不在m_ids中：已提交，可见

3.3 索引原理与优化

3.3.1 B+树索引结构

B+树特点：

1. 多路平衡查找树
2. 非叶子节点只存key不存data
3. 叶子节点包含全部key和data
4. 叶子节点通过指针相连形成链表

与B树对比优势：

1. 更高的扇出（更多子节点）
2. 更稳定的查询性能（所有查询到叶子节点）
3. 更适合范围查询（叶子节点链表）

InnoDB索引实现：

1. 聚簇索引：主键索引，叶子节点存储完整数据
2. 二级索引：非主键索引，叶子节点存储主键值

3.3.2 索引类型

1. 主键索引：

   • 唯一且非空
   • 默认创建聚簇索引
   • 建议使用自增整型

2. 唯一索引：

   • 保证列值唯一
   • 允许NULL值
   • 性能优于普通索引

3. 普通索引：

   • 最基本的索引类型
   • 无唯一性限制

4. 联合索引：

   • 多列组合索引
   • 遵循最左前缀原则
   • 索引复用

5. 覆盖索引：

   • 查询列都在索引中
   • 避免回表操作
   • 性能最佳

3.3.3 索引优化策略

创建原则：

1. 为查询条件列创建索引
2. 为排序和分组列创建索引
3. 选择区分度高的列
4. 使用短索引（前缀索引）
5. 避免过度索引

SQL优化：

1. 避免索引失效：

   • 不使用函数或运算
   • 避免隐式类型转换
   • 避免使用!=或<>操作符
   • 避免使用OR连接条件
   • 避免使用前导通配符LIKE

2. 利用索引排序：

   • ORDER BY子句与索引顺序一致
   • 多字段排序方向一致

3. 使用索引覆盖：

   • 只查询索引包含的列
   • 使用EXPLAIN查看"Using index"

索引失效场景分析：

sql复制-- 索引失效示例
SELECT * FROM users WHERE LEFT(name,3) = 'abc';  -- 使用函数
SELECT * FROM users WHERE age+1 > 20;            -- 使用运算
SELECT * FROM users WHERE phone = 13800138000;   -- 类型转换
SELECT * FROM users WHERE name LIKE '%abc';      -- 前导通配符

3.4 锁机制深入解析

3.4.1 锁类型

按粒度分：

1. 表锁：

   • 锁定整张表
   • 实现简单，开销小
   • 并发度低
   • MyISAM默认锁

2. 行锁：

   • 锁定单行记录
   • 开销大，并发度高
   • InnoDB默认锁

3. 页锁：

   • 锁定一页(通常4KB)
   • 介于表锁和行锁之间
   • BDB引擎使用

按兼容性分：

1. 共享锁(S锁)：

   • SELECT ... LOCK IN SHARE MODE
   • 允许其他事务读但不可写
   • 可被多个事务同时持有

2. 排他锁(X锁)：

   • SELECT ... FOR UPDATE
   • 阻止其他事务读写
   • 只能被一个事务持有

InnoDB特殊锁：

1. 意向锁：

   • 表级锁
   • IS锁：意向共享锁
   • IX锁：意向排他锁
   • 用于快速判断表是否被锁定

2. 间隙锁(Gap Lock)：

   • 锁定索引记录间隙
   • 防止幻读
   • 只在RR隔离级别生效

3. 临键锁(Next-Key Lock)：

   • 记录锁+间隙锁组合
   • 锁定记录及前面间隙
   • InnoDB默认行锁算法

3.4.2 死锁处理

死锁产生条件：

1. 互斥条件
2. 占有且等待
3. 不可抢占
4. 循环等待

InnoDB死锁检测：

1. 等待图(wait-for graph)检测
2. 发现死锁后回滚代价小的事务

避免死锁策略：

1. 事务保持简短
2. 按固定顺序访问表和行
3. 合理设计索引减少锁冲突
4. 使用低隔离级别
5. 设置锁等待超时(innodb_lock_wait_timeout)

死锁排查：

sql复制-- 查看当前锁信息
SHOW ENGINE INNODB STATUS;

-- 查看锁等待
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

3.5 SQL优化与执行计划

3.5.1 EXPLAIN详解

关键字段解析：

1. id：执行顺序，越大优先级越高
2. select_type：
   • SIMPLE：简单查询
   • PRIMARY：最外层查询
   • SUBQUERY：子查询
   • DERIVED：派生表
3. table：访问的表
4. type（性能关键）：
   • system > const > eq_ref > ref > range > index > ALL
5. possible_keys：可能使用的索引
6. key：实际使用的索引
7. key_len：使用的索引长度
8. ref：索引的哪一列被使用
9. rows：预估需要读取的行数
10. Extra：
    • Using index：覆盖索引
    • Using filesort：额外排序
    • Using temporary：使用临时表

3.5.2 常见优化场景

JOIN优化：

1. 确保ON/USING子句列有索引
2. 小表驱动大表
3. 避免复杂JOIN，可拆分为多个查询

子查询优化：

1. 使用JOIN替代子查询
2. 使用EXISTS替代IN
3. 将派生表转换为JOIN

分页优化：

sql复制-- 低效写法
SELECT * FROM users ORDER BY id LIMIT 10000, 20;

-- 优化写法(利用索引覆盖)
SELECT * FROM users WHERE id >= (SELECT id FROM users ORDER BY id LIMIT 10000, 1) LIMIT 20;

COUNT优化：

1. COUNT(*)与COUNT(1)性能相当
2. COUNT(列)不统计NULL值
3. 大数据量考虑使用近似值或维护计数表

3.5.3 数据库设计规范

1. 命名规范：

   • 使用小写字母和下划线
   • 表名复数，字段名单数
   • 避免使用关键字

2. 字段设计：

   • 选择合适的数据类型
   • 避免使用NULL
   • 主键使用自增整型
   • 适当冗余减少JOIN

3. 表设计：

   • 控制单表字段数(<50)
   • 大字段拆分到单独表
   • 遵循第三范式但适当反范式化

4. 索引设计：

   • 单表索引不超过5个
   • 联合索引字段不超过5个
   • 区分度低的列不加索引

4. 面试实战与经验分享

4.1 面试问题分类解析

4.1.1 基础概念类问题

典型问题：

• 什么是Java内存模型？
• 解释一下volatile关键字的作用
• synchronized和ReentrantLock的区别
• HashMap和ConcurrentHashMap的实现原理

回答策略：

1. 简明扼要定义核心概念
2. 结合实际应用场景
3. 适当对比相关技术
4. 可补充性能考量

**