Java 核心基础深度 —— 面试高频考点

数据结构演进：
JDK7：数组 + 链表（头插法，扩容时可能死循环）
JDK8：数组 + 链表 + 红黑树（尾插法，解决死循环）

put() 流程：
1. 计算 hash → (h = key.hashCode()) ^ (h >>> 16)   // 高低 16 位异或，减少碰撞
2. 定位桶位 → (n - 1) & hash                       // 相当于 hash % n，位运算更快
3. 桶为空 → 直接放入
4. 桶有值 → 判断是链表还是红黑树
   - 链表：尾插法，遍历比较 key，相同则覆盖，否则插入尾部
   - 树节点数 ≥ 8 且数组长度 ≥ 64 → 链表转红黑树
   - 树节点数 ≤ 6 → 红黑树转链表
5. size++ 后检查是否超过 threshold，超过则扩容（2 倍）

1. put() 时多线程数据覆盖：两个线程同时 hash 到同一空桶，后写入的覆盖先写入的
2. resize() 时可能形成死循环（JDK7 头插法）：多线程同时扩容时链表可能成环
3. size++ 非原子操作：多线程 put 后 size 可能偏小
4. ConcurrentmodificationException：迭代时其他线程修改抛出此异常

核心机制：CAS + synchronized + volatile

put() 流程：
1. 计算 hash，定位桶位
2. 桶为空 → CAS 尝试写入（自旋，无锁）
3. 桶不为空 → synchronized 锁住桶的头节点
4. 桶内链表/红黑树操作在锁保护下进行
5. 扩容时可多线程协助（transfer() 多线程迁移数据）

为什么比 HashTable 快？
- HashTable 对所有操作加同一把锁（全表锁）
- ConcurrentHashMap 只锁当前桶（桶级别锁），并发度 = 桶数量

class Node<K,V> {
    final int hash;
    final K key;
    V value;
    Node<K,V> next;
}

// 核心方法签名
V put(K key, V value);
V get(K key);
Node<K,V>[] resize();  // 扩容

核心数据结构：
- state（volatile int）：同步状态，0=未锁，1=已锁
- CLH 队列（双向链表）：存放等待获取锁的线程
- Node 节点：封装线程 + 等待状态（SIGNAL/CANCELLED/CONDITION）

加锁流程：
1. CAS 尝试将 state 从 0 改为 1
2. 成功 → 当前线程持有锁
3. 失败 → 线程封装为 Node 节点，加入 CLH 队列尾部（CAS 入队）
4. 前驱节点是 head → 再次尝试获取锁
5. 前驱节点不是 head → park() 挂起当前线程

解锁流程：
1. state 减为 0
2. unpark() 唤醒 CLH 队列中 head 的下一个节点

ThreadPoolExecutor(
    corePoolSize,        // 核心线程数（常驻线程）
    maximumPoolSize,     // 最大线程数
    keepAliveTime,       // 空闲线程存活时间
    unit,                // 时间单位
    workQueue,           // 阻塞队列（存放等待执行的任务）
    threadFactory,       // 线程工厂（自定义线程名）
    rejectedExecutionHandler  // 拒绝策略
)

执行流程：
1. 当前线程数 < corePoolSize → 创建新线程执行
2. 当前线程数 ≥ corePoolSize → 放入 workQueue 等待
3. workQueue 满了 → 创建新线程（直到 maximumPoolSize）
4. 线程数 = maximumPoolSize 且 workQueue 满了 → 执行拒绝策略

4 种拒绝策略：
- AbortPolicy（默认）：抛 RejectedExecutionException
- CallerRunsPolicy：由提交任务的线程自己执行
- DiscardPolicy：直接丢弃（不抛异常）
- DiscardOldestPolicy：丢弃 workQueue 中最老的任务

CPU 密集型：corePoolSize = CPU 核数 + 1
IO 密集型：corePoolSize = CPU 核数 × 2（或 CPU 核数 / (1 - 阻塞系数)）
混合型：分别设置两个线程池

实际生产建议：基于压测数据调优，公式只作参考。

三大特性：
1. 可见性：一个线程修改后，其他线程立即可见（MESI 缓存一致性协议 + 内存屏障）
2. 有序性：禁止指令重排序（内存屏障）
3. 不保证原子性：i++ 这类复合操作仍不安全

使用场景：
- 状态标志位：volatile boolean flag = false;
- 双重检查锁（DCL）单例：instance 必须声明为 volatile
- CAS 中的 value（AtomicInteger 内部使用 volatile int value）

JVM 运行时数据区：

线程共享：
├── 堆（Heap）：对象实例，GC 主战场
│   ├── 年轻代：Eden + S0 + S1（8:1:1）
│   └── 老年代
└── 方法区/元空间：类信息、常量、静态变量（JDK8+ 移入本地内存）

线程私有：
├── 程序计数器：当前线程执行的字节码行号
├── 虚拟机栈：栈帧（局部变量表 + 操作数栈 + 方法出口）
└── 本地方法栈：Native 方法调用

1. 内存布局：CMS 连续分代，G1 将堆划分为大小相等的 Region（1-32MB）
2. 碎片化：CMS 标记-清除导致碎片，G1 标记-整理 + 复制减少碎片
3. 停顿可控：G1 可设置最大停顿时间（-XX:MaxGCPauseMillis）
4. 巨型对象：G1 专有 Humongous Region 处理大对象
5. 预测模型：G1 根据历史数据预测 Region 回收耗时

堆内存：
-Xms4g         初始堆大小
-Xmx4g         最大堆大小
-Xmn2g         年轻代大小
-XX:NewRatio   老年代:年轻代比例（默认 2，即老年代占 2/3）

GC 选择：
-XX:+UseG1GC         使用 G1
-XX:+UseZGC          使用 ZGC（JDK 15+）
-XX:+UseParallelGC   使用 Parallel

GC 日志（JDK 8）：
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/path/to/gc.log

GC 日志（JDK 9+）：
-Xlog:gc*:file=/path/to/gc.log:time,level,tags

OOM 排查：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/path/to/dump.hprof

Channel（通道）：双向读写，如 FileChannel、SocketChannel
Buffer（缓冲区）：读写数据的内存块，flip() 切换读写模式
Selector（选择器）：单个线程监控多个 Channel 的事件（OP_READ/OP_WRITE/OP_CONNECT/OP_ACCEPT）

传统传输：磁盘 → 内核缓冲区 → 用户缓冲区 → Socket 缓冲区 → 网卡（4 次拷贝，4 次上下文切换）
零拷贝（sendfile）：磁盘 → 内核缓冲区 → Socket 缓冲区 → 网卡（3 次拷贝，2 次上下文切换）
零拷贝（mmap）：磁盘映射到内核缓冲区，用户空间和内核空间共享（减少 1 次拷贝）

Kafka 高性能原因之一：大量使用零拷贝技术

核心类：
- Class：类的元信息入口
- Constructor：构造器
- Method：方法
- Field：属性

获取 Class 对象的 3 种方式：
1. Class.forName("com.example.User")
2. User.class
3. user.getClass()

应用场景：
- Spring IOC 容器实例化 Bean
- MyBatis Mapper 接口动态代理
- 注解处理器（运行时解析注解）
- 序列化/反序列化（Jackson/Gson）

□ HashMap put() 流程能默写出来
□ ConcurrentHashMap JDK7 vs JDK8 的区别能说清
□ AQS 的 CLH 队列 + state + CAS 机制理解
□ 线程池 7 参数 + 4 种拒绝策略能默写
□ JVM 内存模型（堆/栈/方法区）能画图
□ G1 vs CMS 的 5 个核心区别
□ JDK 动态代理 vs CGLIB 的 2 个关键差异
□ 10 种设计模式各能说出 1 个 Spring 应用场景