关于Java八股中那些应知必会的事

1、JVM是什么？

把JVM想象成「万能翻译官+工厂流水线」

1. 你写的Java代码  就像一本《英文操作手册》（因为电脑只懂0和1，但人类写英文更方便）。

2. JVM的作用  一个超级翻译官+工厂，它：

   •  翻译：把英文手册（Java代码）逐句翻译成机器能懂的方言（字节码）。

   • ️ 执行：指挥电脑的CPU、内存等硬件，像流水线一样按翻译好的指令干活。

   • ️ 兜底：万一手册里有错误（比如让机器“用空气造手机”），JVM会直接喊停，防止工厂爆炸（系统崩溃）。

---

为什么需要JVM？三大核心价值：

1. 跨平台：

   • 同一本Java手册（代码），交给不同国家的JVM（Windows/Linux/Mac版），都能翻译成当地机器方言。

   • ❌ 没有JVM的话：你得为每个操作系统重写一遍代码，累死程序员。

2. 自动管理内存：

   • JVM自带清洁工（垃圾回收GC），自动扫除程序用完的垃圾内存，避免内存泄漏（类似工厂垃圾堆满后瘫痪）。

   • ❌ 没有JVM的话：像C++程序员得自己倒垃圾，稍不注意就内存溢出。

3. 安全沙箱：

   • Java程序运行在JVM的隔离沙箱里，比如你下载的小游戏无法偷删你电脑的文件。

   • ❌ 没有JVM的话：恶意代码可能直接攻击你的硬盘。

---

⚡ 举个实际例子：

当你用电脑打开一个《我的世界》Java版游戏：

1. 游戏代码（Java编写） → 交给JVM → JVM根据你的操作系统翻译成机器指令 → 游戏流畅运行。

2. 如果你在Windows和Mac上玩同一份游戏，只需装对应的JVM，游戏代码不用改。

---

JVM是Java的核心保镖+翻译+保姆，让程序员写一次代码到处运行，还不用操心内存和安全问题。没有它，Java可能早就消失了。

2、ThreadLocal是什么？

 ThreadLocal 是什么？

想象你上班时，公司给每个员工（线程）发了一个 私人储物柜（ThreadLocal）。

• 你的东西（数据）只能你自己存取，别人碰不到，也看不到。

• 避免大家共用同一个柜子（共享变量）时，互相拿错东西的混乱场面。

一句话：ThreadLocal 是给每个线程单独存数据的“私有保险箱”。

---

️ ThreadLocal 有什么用？

1. 线程隔离：

   • 多线程同时操作时，防止数据互相干扰（比如：A线程改了自己的数据，不小心把B线程的数据也改了）。

   • 典型场景：用户登录信息、数据库连接、SimpleDateFormat（这货不是线程安全的！）。

2. 避免传参：

   • 把需要跨方法调用的数据（比如用户ID）塞到ThreadLocal里，后续直接用，不用层层传递参数。

举个栗子：

// 定义一个“储物柜”（存储用户ID）
static ThreadLocal userStorage = new ThreadLocal<>();

// 线程A存数据
userStorage.set("用户A的ID"); 

// 线程A在任何地方都能取自己的数据
System.out.println(userStorage.get()); // 输出"用户A的ID"

// 线程B存自己的数据（和线程A互不干扰）
userStorage.set("用户B的ID");

---

⚙️ 底层实现（简化版）

1. 每个线程（Thread）内部有一个隐藏的 ThreadLocalMap（类似一个私人抽屉）。

2. 当你调用 threadLocal.set(value)：

   • 实际上是往 当前线程的私人抽屉 里存数据，key是ThreadLocal对象本身，value是你存的值。

   // 伪代码解释
   Thread.currentThread().threadLocalMap.set(this, value);

3. 当你调用 threadLocal.get()：

   • 是从当前线程的抽屉里，用ThreadLocal对象当key取出对应的value。

关键点：

• 数据是存在线程对象里的，不是存在ThreadLocal里！

• ThreadLocal 只是帮你操作线程私有数据的“工具人”。

---

 注意事项

1. 内存泄漏：

   • 如果线程池复用线程（比如Web服务器），用完必须 remove() 清理数据，否则可能导致内存泄漏（因为线程一直活着，数据一直被引用）。

2. 不要滥用：

   • 如果数据本来就该共享（比如全局配置），用ThreadLocal反而增加复杂度。

---

 再举个现实例子

• 场景：银行有4个窗口（4个线程），每个窗口的柜员需要记录当前办理业务的客户ID。

• 不用ThreadLocal：所有柜员共用一个白板写客户ID，可能互相覆盖。

• 用ThreadLocal：每个柜员自己带一个小本本（ThreadLocal），只记自己的客户ID，互不干扰。

---

ThreadLocal = 线程的私有储物柜，解决多线程数据冲突问题，底层靠线程自己的ThreadLocalMap实现隔离。

2.1、那什么是ThreadLocalOOM内存泄漏？

 ThreadLocal内存泄漏是什么？

想象一个场景：

1. 你辞职了（线程任务结束），但你的 私人储物柜（ThreadLocal） 里还堆满了东西（数据）。

2. 由于柜子的钥匙（ThreadLocal引用）和你的工牌（线程对象）没被销毁，清洁工（垃圾回收器GC）以为这些垃圾还有用，不敢清理。

3. 久而久之，公司（JVM）的储物区（内存）被塞满，最终爆仓（OOM内存溢出）。

本质：ThreadLocal使用不当，导致无用数据无法被GC回收，占满内存。

---

 为什么会泄漏？（底层原理）

关键在于这两点：

1. ThreadLocalMap 的key是弱引用，value是强引用：

   • 弱引用key：如果外界没有强引用指向ThreadLocal对象（比如threadLocal=null），GC时会回收key。

   • 强引用value：但对应的value依然被ThreadLocalMap强引用，无法被回收！

2. 线程池的线程长期存活：

   • 比如Tomcat的线程池会复用线程，线程不会销毁 → 它的ThreadLocalMap一直存在 → 泄漏的value越积越多。

伪代码演示泄漏：

static ThreadLocal threadLocal = new ThreadLocal<>();

void doSomething() {
    threadLocal.set(new byte[1024 * 1024]); // 存1MB数据
    // 忘记调用 threadLocal.remove()！
} 
// 虽然threadLocal=null，但value还在ThreadLocalMap中占用内存！

---

 内存泄漏的流程

1. ThreadLocal对象失去强引用（比如置为null或方法结束）。

2. GC回收弱引用的key（因为只有弱引用指向ThreadLocal）。

3. 但value仍被ThreadLocalMap强引用 → 形成key=null, value=占用内存的无效条目。

4. 线程池的线程长期存活 → 无效条目越来越多 → 最终OOM。

---

️ 如何避免内存泄漏？

1. 用完必须 remove()：

   try {
       threadLocal.set(data);
       // ...业务代码
   } finally {
       threadLocal.remove(); // 强制清理！
   }

2. 尽量用static修饰ThreadLocal：

   • 减少ThreadLocal实例数量（非static时，每次new对象都会创建新ThreadLocal）。

3. 避免存储大对象：

   • 比如存1MB的byte数组，泄漏时危害更大。

---

 现实类比

• 场景：健身房更衣室的储物柜（ThreadLocal）。

• 泄漏：会员（线程）退卡后，柜子里的衣物（value）没清空，但管理员（GC）以为钥匙（key）还在，不敢清理。

• 结果：更衣室爆满（OOM），新会员没柜子可用。

---

 总结

1. 泄漏原因：

   • ThreadLocalMap的key弱引用被回收，value强引用无法回收 + 线程长期存活。

2. 危害：

   • 内存中堆积大量无用数据 → OOM（尤其在线程池场景）。

3. 解决方案：

   • 用完立即remove()！

   • 就像退租前清空房间，避免被扣押金（内存）！

3、四种引用 ：强引用 软引用 弱引用 虚引用

 1. 强引用（Strong Reference）

 特点

• 默认的引用类型，只要强引用存在，对象就不会被GC回收，即使内存不足（OOM 也不回收）。

• 比如：Object obj = new Object();，obj 就是强引用。

 示例

Object obj = new Object(); // 强引用
obj = null; // 取消强引用，此时对象可以被GC回收

 现实比喻

• 就像你手里紧紧握着一把钥匙（强引用），只要你不松手（obj 不置为 null），这把钥匙对应的门（对象）就永远不会被拆掉（GC 回收）。

---

 2. 软引用（Soft Reference）

 特点

• 内存不足时才会被回收（GC 发现内存不够时，会清理软引用对象）。

• 适用于缓存场景（比如图片缓存），内存紧张时自动释放。

 示例

SoftReference softRef = new SoftReference<>(new byte[1024 * 1024]); // 1MB 数据
byte[] data = softRef.get(); // 获取对象（可能已被GC回收）
if (data == null) {
    System.out.println("对象已被GC回收");
}

 现实比喻

• 就像公司里的临时工位（软引用），平时可以正常使用，但如果公司空间紧张（内存不足），HR（GC）会优先清理这些工位。

---

 3. 弱引用（Weak Reference）

 特点

• 只要发生GC，就会被回收（不管内存是否充足）。

• 典型应用：ThreadLocal、WeakHashMap（防止内存泄漏）。

 示例

WeakReference weakRef = new WeakReference<>(new byte[1024]); // 1KB 数据
System.gc(); // 手动触发GC（仅示例，生产环境不要用！）
byte[] data = weakRef.get(); // 大概率返回 null
if (data == null) {
    System.out.println("对象已被GC回收");
}

 现实比喻

• 就像临时便签（弱引用），只要保洁阿姨（GC）来打扫，就会直接撕掉（回收），不管办公室是否拥挤。

---

 4. 虚引用（Phantom Reference）

 特点

• 最弱的引用，无法通过 get() 获取对象，仅用于跟踪对象被GC回收的时机。

• 必须配合 ReferenceQueue 使用，适用于资源清理（如堆外内存管理）。

 示例

ReferenceQueue