Java常见基础面试题｜高频考点深度解析｜附真题示例与避坑指南

Q1：Java堆内存分代模型是怎样的？新生代/老年代比例默认是多少？

标准答案：
Java堆分为：新生代（Young Gen） + 老年代（Old Gen）。
默认比例：Eden:S0:S1 = 8:1:1（即新生代中Eden占80%，两个Survivor各占10%）；新生代:老年代 = 1:2（可通过-Xmn调整）。总堆大小默认为物理内存的1/4。

考察延伸：
• 若频繁创建大对象（如大数组），可能直接进入老年代（通过-XX:PretenureSizeThreshold设置阈值）
• 对象晋升条件：
- Survivor区对象年龄达阈值（默认15，可通过-XX:MaxTenuringThreshold调整）
- 动态年龄判断：Survivor中同龄对象总大小 > 50% Survivor区 → 年龄≥该龄对象全部进入老年代
- 老年代空间分配担保失败（HandlePromotionFailure）

// 示例：验证大对象直接进入老年代（JDK8）
public class DirectToOldGen {
    public static void main(String[] args) {
        // 设置堆大小：新生代40MB，老年代60MB
        byte[] bigArray = new byte[10 * 1024 * 1024]; // 10MB大对象
        System.out.println("对象已创建");
    }
}

Q2： Minor GC、Major GC、Full GC触发条件分别是什么？

Q3：HashMap在JDK1.7与JDK1.8中的核心区别是什么？

1. 数据结构
• JDK1.7：数组 + 链表
• JDK1.8：数组 + 链表 + 红黑树（链表长度≥8且数组长度≥64时转红黑树）

2. 插入方式
• JDK1.7：头插法（可能导致多线程下形成死循环）
• JDK1.8：尾插法（避免环形链表）

3. 扩容机制
• JDK1.7：重新计算hash（rehash）
• JDK1.8：利用hash高位运算优化，元素位置要么不变，要么变为原索引+oldCapacity

4. 线程安全
两者均非线程安全，并发场景需用ConcurrentHashMap。

// JDK1.8扩容核心代码片段（简化版）
Node[] newTab = new Node[newCap];
for (Node e : oldTab) {
    if (e.next == null)
        newTab[e.hash & (newCap - 1)] = e;
    else if (e instanceof TreeNode)
        ((TreeNode)e).split(...);
    else { // 链表
        Node loHead = null, loTail = null;
        Node hiHead = null, hiTail = null;
        Node next;
        do {
            next = e.next;
            if ((e.hash & oldCap) == 0) { // 低位链表
                if (loTail == null) loHead = e;
                else loTail.next = e;
                loTail = e;
            } else { // 高位链表（原索引+oldCap）
                if (hiTail == null) hiHead = e;
                else hiTail.next = e;
                hiTail = e;
            }
        } while ((e = next) != null);
        newTab[oldIndex] = loHead;
        newTab[oldIndex + oldCap] = hiHead;
    }
}

Q4：ArrayList与LinkedList适用场景对比？

典型陷阱：
• 在中间位置插入元素时，ArrayList需移动后续所有元素，性能可能远低于LinkedList
• 但若插入位置接近末尾，ArrayList优势明显（CPU缓存局部性好）

Q5：ConcurrentHashMap在JDK1.7与1.8的实现差异？

JDK1.7：
• 分段锁（Segment数组 + HashEntry链表）
• Segment继承ReentrantLock，每个Segment独立加锁
• 并发度 = Segment数量（默认16）

JDK1.8：
• 取消Segment，采用Node数组 + 链表/红黑树
• 锁粒度细化为节点级（synchronized + CAS）
• 插入时：
- 首节点用CAS + synchronized保证原子性
- 非首节点用synchronized锁住链表头
• 并发度 = 数组长度（默认16）

性能对比：
JDK1.8在低并发时性能提升30%+，高并发时更稳定（无锁竞争瓶颈）。

Q6：volatile关键字的作用与原理？

三大特性：
① 可见性：线程修改后立即写回主存，其他线程立即可见
② 禁止指令重排序：通过内存屏障实现
③ 不保证原子性（需配合CAS）

内存屏障示例：
• volatile写前插入：StoreStore屏障（禁止写重排序）
• volatile写后插入：StoreLoad屏障（防止写与后续读重排序）
• volatile读前插入：LoadLoad屏障
• volatile读后插入：LoadStore屏障

典型应用：
• 单例模式的双重检查锁（DCL）
• 状态标记（如线程中断标志）

// 正确的DCL单例（volatile + synchronized）
public class Singleton {
    private static volatile Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton(); // 1.分配内存 2.初始化 3.赋值
                }
            }
        }
        return instance;
    }
}

Q7：线程池的核心参数及拒绝策略？

拒绝策略对比：

• AbortPolicy：抛出RejectedExecutionException（默认）
• CallerRunsPolicy：由调用线程执行任务（适合低优先级任务）
• DiscardPolicy：直接丢弃任务（静默失败）
• DiscardOldestPolicy：丢弃队首任务，尝试插入新任务

⚠️ 避坑指南：
• 禁用Executors工具类创建线程池（易OOM）
• 必须自定义ThreadFactory，避免线程名混乱
• 阻塞队列建议使用有界队列（如ArrayBlockingQueue）防止OOM

Q8：synchronized的锁升级过程？

锁状态流转：
无锁 → 偏向锁 → 轻量级锁 → 重量级锁

详细过程：
① 无锁：对象初始状态
② 偏向锁（单线程）：
- 第一次获取锁时，JVM将对象头Mark Word设为偏向模式
- 后续获取直接CAS更新ThreadID，无需原子操作
- 若有竞争，升级为轻量级锁
③ 轻量级锁（多线程竞争但非激烈）：
- 通过CAS尝试获取锁（自旋）
- 成功则执行，失败则自旋等待
④ 重量级锁（自旋失败）：
- 线程挂起，进入阻塞队列
- 由操作系统调度

锁消除与偏向锁禁用：
• JDK15+默认禁用偏向锁（因多核时代竞争少）
• 可通过-XX:+UseBiasedLocking启用（仅适合单线程场景）

Q9：BIO、NIO、AIO的核心区别？

NIO三大核心组件：
• Channel（通道）：双向数据传输（类似流）
• Buffer（缓冲区）：数据容器（如ByteBuffer）
• Selector（选择器）：多路复用器，监听多个Channel事件

Selector工作原理：
① Channel注册到Selector（需设置OP_READ/OP_WRITE）
② select()阻塞等待事件发生
③ 事件触发后，通过SelectionKey获取Channel
④ 处理事件（如读取数据）

Q10：零拷贝（Zero-Copy）技术原理？

传统IO流程（4次拷贝 + 4次上下文切换）：
① DMA将磁盘数据拷贝到内核缓冲区
② 内核缓冲区 → 用户缓冲区（CPU拷贝）
③ 用户缓冲区 → Socket缓冲区（CPU拷贝）
④ Socket缓冲区 → 网卡（DMA）

零拷贝方案：
• mmap + write：减少1次CPU拷贝（内核→用户），但仍有4次上下文切换
• sendfile（Linux2.1+）：1次系统调用完成，仅2次上下文切换 + 2次DMA
• splice（Linux2.6.17+）：内核管道，完全零拷贝（无用户缓冲区）

Java中实现：
• MappedByteBuffer（mmap）
• FileChannel.transferTo()（sendfile）

// 使用sendfile实现零拷贝（FileChannel）
try (FileInputStream fis = new FileInputStream("large.dat");
     FileChannel inChannel = fis.getChannel();
     FileOutputStream fos = new FileOutputStream("copy.dat");
     FileChannel outChannel = fos.getChannel()) {
    // 零拷贝传输
    inChannel.transferTo(0, inChannel.size(), outChannel);
}

Q11：Spring中常用的设计模式及应用场景？

Q12：单例模式的8种写法及安全性对比？

枚举单例示例（最安全）：

public enum Singleton {
    INSTANCE;
    public void doSomething() {
        // 业务逻辑
    }
}

优势：
• 自动支持序列化机制
• 天然防止反射攻击（Enum构造器私有）
• JVM保证单例唯一性

Q13：Spring Bean的完整生命周期？

标准流程（9步）：

1. 实例化：BeanWrapper创建Bean实例
2. 属性赋值：populateBean()填充属性
3. 初始化前：applyBeanPostProcessorsBeforeInitialization()
4. 初始化：
   - 调用Aware接口（BeanNameAware/BeanFactoryAware）
   - 调用InitializingBean.afterPropertiesSet()
   - 调用自定义init-method
5. 初始化后：applyBeanPostProcessorsAfterInitialization()
6. 使用：Bean准备就绪
7. 销毁前：DisposableBean.destroy()
8. 销毁：自定义destroy-method

典型陷阱：
• BeanPostProcessor的postProcessBeforeInitialization()在init之前
• @PostConstruct注解方法在afterPropertiesSet()之前执行

Q14：@Transactional失效的8大场景及解决方案？

Q15：final、finally、finalize的区别？

• final：
  • 修饰类：不可继承
  • 修饰方法：不可重写
  • 修饰变量：常量（基本类型值不可变，引用类型地址不可变）
• finally：
  • try-catch的finally块，确保代码执行（即使异常）
• finalize：
  • Object方法，GC回收前调用（JDK9已废弃，不推荐使用）

陷阱：
• finalize()执行时间不确定，可能不被执行
• 若finalize()抛出异常，GC将终止对象清理

Q16：equals()与==的区别？

==：
• 基本类型：比较值
• 引用类型：比较内存地址

equals()：
• Object默认行为 = ==
• String/Integer等重写后比较内容
• 必须满足5条性质：
- 自反性（x.equals(x) = true）
- 对称性（x.equals(y) = y.equals(x)）
- 传递性（x=y, y=z → x=z）
- 一致性（多次调用结果不变）
- 非空性（x.equals(null) = false）

重写equals()必须重写hashCode()！

// 错误示例：只重写equals未重写hashCode
class Person {
    String name;
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return Objects.equals(name, person.name);
    }
    // 缺少hashCode() → HashMap中可能重复存储！
}

Q17：Java泛型的类型擦除原理？

擦除规则：
① 无界泛型（如List）→ 擦除为原始类型（List）
② 有界泛型（如）→ 擦除为边界类型（Number）
③ 泛型方法参数 → 擦除为Object（或边界类型）

擦除后的影响：
• 无法通过反射获取泛型实际类型（需用TypeToken workaround）
• 不能创建泛型数组（new T[] → new Object[]）
• 不能instanceof泛型类型（if (obj instanceof T) ❌）

解决方案：
• 使用Class参数传递类型信息
• 使用通配符（? extends Number）