Java基础八：String、HashMap、单例等8大核心问题全解析

做Java开发这些年我越来越发现一个很反直觉的事实真正让程序员拉开差距的往往不是谁会用更新潮的框架而是谁对Java基础的理解更透彻。平时大家刷“Java面试题”或者看“Java八股文”的时候应该都有同样的感受——面试官最爱问的就是基础最能把人问住的也是基础。很多知识点你以为自己会了可真到要讲清楚“为什么”的时候又说不利索。这一期正好是我们“Java基础”系列的第八篇所以我把它叫作「java基础八」专门聊聊那些高频、高价值、但又特别容易被忽略的核心问题。不管你是准备Java面试还是刚入行想把地基打牢这篇文章都值得你花半小时慢慢看。我会尽量不让你只是背答案而是把背后的原理、代码验证、面试怎么答一次讲透。1. 为什么要把“Java基础”这个老话题翻出来再讲一遍1.1 基础扎实的人到底强在哪里我见过不少工作了一两年的同学Spring Boot、分布式、消息队列这些名词都能聊项目也能跑起来但一被问到“HashMap 怎么扩容”“接口和抽象类到底怎么选”“String 为什么不可变”就开始支支吾吾。这不是因为他们不聪明而是因为学习路径里少了基础这块压舱石。基础的价值其实体现在三个层面。第一是排查问题懂底层原理的人遇到bug能快速判断是“用错了API”还是“设计本身有问题”而不是靠试错猜答案。第二是做技术选型理解了底层机制你就知道某个框架为什么这样设计而不是人云亦云。第三是面试能把一个基础问题讲出层次感的人通常会被默认“技术深度不错”。所以与其堆砌一堆项目名词不如先把基础点真正吃透。1.2 这期“java基础八”的核心问题清单按照基础系列一贯的风格这一期我挑了8个常出现在面试题和日常踩坑现场的问题来拆解String 的不可变性到底怎么影响你的日常开发 和 equals 的边界什么时候该用哪一个重载和重写怎么讲出面试官想听的区别接口与抽象类选不好就是设计没想清楚ArrayList 和 LinkedList不能只会背“数组 vs 链表”HashMap 的核心机制哈希、冲突、扩容与线程安全单例模式的线程安全问题手写时不翻车受检异常与非受检异常Java异常体系的正确打开方式这8个问题都是基础题里的老熟人但我觉得真正理解它们的人并不多。这一章我们挨个拆每个问题都按“结论、原理、代码验证、面试答法”的顺序来展开。2. 核心细节解析把这8个Java基础问题逐个吃透2.1 为什么说String不可变不只是“面试考点”String类用 final 修饰内部用 private final char value[] 存储字符JDK 9之后改成了 byte[]这决定了它一旦创建内容就不能被改变。很多同学知道“String不可变”但再往下追问一句“这个不可变到底保护了什么”就答不上来了。换个角度想String是Java里使用频率最高的对象之一如果它的内容能随意变化那哈希缓存、字符串常量池、类加载过程中的类名、配置项的key全都可能乱套。正因为String不可变它的 hashCode 才能被安全缓存也正因为不可变常量池才能放心复用同一个对象不怕被某个地方不小心改掉。日常开发里最常见的误用是在循环里用 String 做拼接。每次 都会生成一个新的String对象循环次数一多内存和GC压力就会变大。这时候正确的做法是用 StringBuilder 或者 StringBuffer。这个例子本身也说明了一个问题你只有理解了不可变才能真正理解为什么需要 StringBuilder而不是机械地背结论。2.2 比较的是引用equals 比较的是内容但这个“内容”要分清几乎所有Java基础面试题都会问“ 和 equals 的区别”。标准答案是 比较的是两个引用是否指向同一个对象equals 默认也是比较引用但很多类会重写它来比较内容。真正的问题在于什么情况下你会踩坑先说包装类的经典坑。Integer 在 -128 到 127 之间会缓存对象所以 Integer a 100; Integer b 100; 用 比较是 true可一旦改成 128结果就变成 false。很多人觉得这是“玄学”其实Integer内部有一个缓存数组只是两个引用恰好指向了缓存里的同一个对象本质上并没有违背 的语义。再看 String。String s1 hello; String s2 new String(hello); 这两个用 比较是 false因为 s2 在堆上新创建了一个对象。但如果都用字面量赋值且内容相同那么它们会指向常量池里的同一个对象 就是 true。所以实际开发中判断两个字符串是否相等一律用 equals。别用 去赌“对象复用”这种不确定的事赌输了就是线上事故。2.3 重载和重写别只背“编译期 vs 运行期”重载Overload发生在同一个类里方法名相同、参数列表不同Java编译器在编译阶段就会决定调用哪一个所以它是静态绑定。重写Override发生在父类和子类之间子类重新实现父类的方法调用时根据对象的实际类型决定所以属于动态绑定。面试如果只说到这其实还不够。我建议在回答时补上几个关键点第一重写要求方法签名相同返回类型可以是协变类型访问修饰符不能比父类更严格第二重写方法抛出的受检异常不能比父类更宽泛第三被 private、static、final 修饰的方法不能被重写但 static 方法可以被“隐藏”这容易和重写混淆。如果面试官继续追问“构造函数能被重写吗”你要能立刻回答构造函数不能被重写但可以被重载。能答到这一层往往比背一堆定义更容易加分。2.4 接口和抽象类选不好就是设计没想清楚接口和抽象类不是“随便用哪个都行”的关系。抽象类是一个“不完整的类”通过 extends 来继承强调“是什么”适合用来抽取多个子类公共的属性和行为接口是一份“能力契约”通过 implements 来实现强调“能做什么”适合用来定义行为规范。Java 8 之后接口里可以有 default 方法和 static 方法这让接口和抽象类的边界看起来模糊了。但设计思路上依然清晰如果你需要保存状态也就是需要成员变量那应该用抽象类如果你只是要定义一个能力让不相关的类都可以实现那应该用接口。我自己早期写支付模块时踩过一个设计上的坑把日志记录、加密逻辑都放在抽象类里又让抽象类实现一个接口。结果新增支付方式时想复用别的公共能力却因为单继承被卡住了代码耦合越来越重。后来改成“接口定义行为、组合引入公共能力”整体清爽很多。所以别为了复用代码而滥用继承接口加组合往往更灵活。2.5 ArrayList 和 LinkedList 的选择不能只看“数组 vs 链表”ArrayList底层是Object数组LinkedList底层是双向链表这个大家都会背。但实际开发里LinkedList的“增删快”并不总是成立。ArrayList 在中间插入时要搬移元素LinkedList 虽然插入本身只需要改指针但如果插入位置在中间它还是要从头或尾遍历到目标位置复杂度同样不低。还有更重要的一点是内存占用。ArrayList 每个元素只要一个引用而 LinkedList 每个节点还需要额外维护前驱和后继两个引用节点本身也是一个对象内存开销明显更大。所以如果你没有频繁在中间插入删除的需求ArrayList 几乎总是更好的选择LinkedList 真正适合的是“频繁在头部操作”的场景比如实现队列。我在本地做过一次简单的压测向一个100万元素的列表头部插入10万次LinkedList明显更占优势但如果按索引随机访问ArrayList几乎碾压。面试时与其背结论不如从“底层结构决定操作复杂度”这个角度去推面试官会觉得你是真有理解而不是临时背书。2.6 HashMap 的原理值得你多花一点时间看HashMap是Java基础里最值得深挖的知识点。它的底层是“数组 链表 红黑树”。put的时候先根据 key 的 hashCode 计算桶位置发生哈希冲突时在同一个桶里用链表存储当链表长度达到阈值默认8且数组长度达到64时链表会转成红黑树。这里的阈值8是官方基于泊松分布算出来的概率平衡点不是随便拍脑袋定的。HashMap线程不安全的问题也很经典。并发 put 时可能出现数据覆盖JDK 7 版本在扩容时甚至可能形成环形链表导致 get 死循环。JDK 8 优化了扩容逻辑采用尾插法环形链表问题基本解决了但数据覆盖、丢失的问题依然存在。所以并发环境下要用 ConcurrentHashMap而不是自己去给 HashMap 加锁。关于容量HashMap 默认负载因子是0.75扩容阈值是 capacity * loadFactor。这个0.75也是空间和时间的平衡太小了浪费内存太大了容易冲突。这些细节如果能自己推算出来或者讲清楚来历面试时就不会显得像在背答案。2.7 单例模式手写能过但问题往往在“线程安全”单例模式是基础中的基础但写法和面试考点差异挺大。最简单的写法是饿汉式直接 new这在多数场景下没问题但如果你想要懒加载就得考虑线程安全。于是有了双重检查锁DCL写法用 volatile 修饰实例变量目的是防止指令重排导致拿到半初始化对象。“为什么一定要加 volatile”这是面试官特别喜欢追问的点。因为 new Singleton() 在底层不是一步完成的分配内存、初始化对象、把引用指向内存这三步可能被编译器或CPU重排。如果重排成“先赋引用再初始化”另一个线程就可能拿到一个“已经分配地址、但还没完成初始化”的对象。volatile 禁止了这种重排才能保证安全。还有一种日常更推荐的写法是使用静态内部类它利用类加载机制天然实现了懒加载和线程安全。面试时如果能把双重检查锁、静态内部类、枚举写法都讲一遍并说清楚各自的优劣会显得你对并发和类加载都有足够深的理解。2.8 受检异常和非受检异常别再被“要不要抛”搞晕Java的异常体系也经常被低估。受检异常checked exception继承自 Exception编译器强制要求处理或声明抛出非受检异常继承自 RuntimeException编译器不强制处理。这个“强制”看似烦人其实是一种设计约束受检异常意味着调用方必须考虑失败场景比如 IOException、SQLException非受检异常往往代表程序逻辑错误比如 NullPointerException、IllegalArgumentException。我见过不少团队喜欢把业务校验失败也定义成 RuntimeException 的子类也有团队习惯把所有业务异常都做成受检异常。两种思路各有道理关键要看调用方能否从这个异常中恢复如果调用方可以进行处理用受检异常能逼着它处理如果这个异常代表“你的调用姿势不对”那用运行时异常更合适。这个判断逻辑远比死记“继承谁”实用得多。3. 实操过程与核心环节实现把基础问题变成能跑的代码3.1 用代码验证 String 的比较与不可变性先看一个特别容易出错的例子。public class StringDemo { public static void main(String[] args) { String s1 hello; String s2 hello; String s3 new String(hello); System.out.println(s1 s2); // true两个字面量指向常量池同一个对象 System.out.println(s1 s3); // falses3 是堆上新建对象 System.out.println(s1.equals(s3)); // true比较内容 String s4 hel lo; // 编译期常量折叠结果等同于 hello System.out.println(s1 s4); // true String s5 hel; String s6 s5 lo; // 变量拼接结果是堆上新对象 System.out.println(s1 s6); // false } }输出结果是 true、false、true、true、false。前两个大家基本都知道后两个才是隐藏考点字面量拼接会被编译器折叠而变量拼接会在运行时生成新的String对象。把这一点看清楚你就不会在写代码时用 去比较字符串也能理解为什么循环拼接字符串一定要用 StringBuilder。关于不可变性还有一个非常容易踩的坑String 的 replace、concat、substring 等方法都返回一个新String不会修改原对象。所以写工具类的时候一定要接收返回值否则你会发现自己调了半天方法原字符串纹丝不动。这类bug虽然不致命但排查起来非常烦人。3.2 写一个线程安全的单例并把原理讲清楚单例模式我推荐日常用静态内部类的写法逻辑清楚不容易踩坑public class Singleton { private Singleton() {} private static class Holder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return Holder.INSTANCE; } }这段代码为什么线程安全因为 JVM 在类初始化阶段会加锁保证一个类只会被加载和初始化一次而 Holder 只有在 getInstance 被调用时才会第一次被加载所以它既实现了懒加载又天然线程安全。它比双重检查锁少了很多容易写错的地方是我个人最推荐的一种写法。如果一定要写双重检查锁那 volatile 一定不能少public class DCLSingleton { private static volatile DCLSingleton instance; private DCLSingleton() {} public static DCLSingleton getInstance() { if (instance null) { synchronized (DCLSingleton.class) { if (instance null) { instance new DCLSingleton(); } } } return instance; } }面试官如果问“为什么不直接用 synchronized 修饰 getInstance”你可以回答那样会让所有读操作串行性能损耗太大。双重检查锁先把大部分读请求挡在锁外只在第一次初始化时才真正竞争锁这就是它存在的意义。3.3 把 HashMap 的哈希、冲突和扩容串起来我建议用实际例子推演一遍 HashMap 的 put 过程。假设 new HashMap(16)负载因子0.75那么扩容阈值是 12。现在 put 一个 key计算流程如下先调用 key.hashCode()再把高位和低位做异或运算也就是“扰动函数”目的是让哈希值分布更均匀最后用 (n - 1) hash 算出桶下标。为什么用 (n - 1) hash 而不是 hash % n因为 HashMap 的容量总是2的幂这样取模运算就能用位运算替代效率更高。这也是为什么扩容时容量总是翻倍而不是随意扩大。当元素数量超过阈值12时数组会扩到32原来的元素就需要重新分配桶位置这就是 rehash。为了验证哈希冲突可以写一个简单demopublic class HashDemo { record Word(String value) { Override public int hashCode() { return 1; // 故意制造大量冲突实际代码千万别这么写 } } public static void main(String[] args) { HashMapWord, Integer map new HashMap(); for (int i 0; i 20; i) { map.put(new Word(word i), i); } System.out.println(map.size()); // 20 } }当所有 hashCode 都返回1时所有 key 都会落入同一个桶HashMap 会先用链表把元素串起来等链表长度超过8且数组长度超过64再转成红黑树。这样做的原因是极端哈希冲突下查询复杂度会从 O(1) 退化到 O(n)转树之后可以降到 O(log n)。这个例子能帮你在面试时把“为什么有红黑树”这件事讲得清清楚楚。4. 常见问题与排查技巧实录基础知识点背得再熟真到写代码和面试时还是会有各种“翻车现场”。这一部分我整理了在实际写代码和面试候选人时经常遇到的高频问题以及对应的排查思路。4.1 面试官连环追问时最容易露馅的几个点第一个高频追问是Integer 用 比较什么时候会出问题如果你只回答“-128到127之间是true”面试官大概率会追问“为什么是这个范围能不能改”。问题的本质是 IntegerCache 的缓存上界可以通过 JVM 参数调整而“缓存”这件事不能靠直觉推断。正确的答法是从缓存机制讲起再补一句“所以包装类比较一律用 equals 更安全”。第二个高频追问是HashMap 允许 null 的 key 和 value但 ConcurrentHashMap 不允许为什么HashMap 允许 null 是为了方便put null key 时会放在下标为0的桶而 ConcurrentHashMap 不允许是因为并发环境下 null 值会有歧义get 返回 null 时你无法判断是 key 不存在还是 value 本身就是 null。这一层原因比“源码就是这么写的”要值钱得多。第三个高频追问是你在项目中哪里真的用到了这些基础这个问题其实是在验证你是否只是在背题。我建议你准备一两个真实案例比如“排查过一次因字符串 比较导致的bug”“用线程安全单例重构过某个工具类”。案例不用大只要真实发生过说服力就远胜于空泛的理论。4.2 写基础代码时最容易翻车的三个场景代码层面的翻车我见得比较多的有三个。第一个是字符串比较。业务代码里用 比较两个不同来源的 String测试环境偶发失效查半天才发现问题。这种问题的排查方式很简单在可疑的比较处打断点看两个变量的对象引用是否一致或者全局搜索 String 类型的 比较基本上一查一个准。第二个是“一边遍历一边删除”。很多人知道用增强 for 循环删除元素会抛 ConcurrentModificationException但不知道原因。本质是迭代器里的 modCount 和 expectedModCount 不一致。正确的删除方式是用迭代器的 remove或者在明确场景下用 removeIf。不懂这个机制你会在各种“先收集再删除”的弯路里浪费不少时间。第三个是单例的“并发重复创建”。我遇到过生产环境偶尔出现多个实例的情况排查后发现是有同事没有从单例方法获取对象而是在别处又重新 new 了一个。所以当你发现“单例不单”的时候要先确认是否所有入口都走同一个方法其次再考虑反射和序列化会不会绕过构造方法这个思路也很适合作为面试时的扩展回答。4.3 我的排查思路和参考口诀遇到这一类基础问题我一般按这个顺序排查先看“是不是用错了API”比如用了 而不是 equals用了 ArrayList 却频繁在头部插删再看“是不是存在并发问题”比如成员变量被多线程读写、单例没做同步最后才看“是不是设计问题”比如抽象类滥用、异常类型选错。有一句话我经常分享给团队新人遇到看起来像“Java 玄学”的bug先问自己三个问题——访问控制符对不对对象是不是同一个并发下有没有竞态这三个问题的命中率真的非常高。学习方面推荐带着问题去读源码不要从头到尾一行行啃。比如想搞清楚 HashMap就先给自己提几个问题哈希冲突了会怎样扩容时旧数据怎么办为什么用红黑树然后去对应源码片段里找答案效率会高很多。基础类的东西读源码的收益往往比看一百篇二手博客都大。5. 这期的内容扩展建议和最后的实操心得5.1 用“讲给别人听”来检验自己是不是真懂了我推荐一个自检方法试着把今天讲的某个知识点比如 HashMap 的扩容机制用你自己的话讲给一个不写Java的朋友听看他能不能听懂。如果讲着讲着自己都卡住了说明你还没吃透。这个方法虽然朴素但用在面试准备上特别灵。你还可以给自己建一个“面试题模拟清单”今天从本文这8题开始后面扩展到20题、50题每道题都从“原理、代码、场景”三个角度准备。不要背标准答案而是把每个问题当成一道“为什么”来回答。真正理解的问题你用任何语言都能表达清楚没理解的换个问法就露馅。5.2 我的真实体会基础决定你能走多远说句实在话写了这么多年Java我见过太多“项目经验一堆、基础一塌糊涂”的简历也见过不少基础扎实、框架上手极快的人。扎实的基础不保证你马上升职加薪但一定会在你遇到奇怪bug、做技术方案、准备面试时成为你最大的底气。如果你现在正处在“会用框架但说不太清原理”的阶段不用急这是几乎每个Java开发者都会经历的阶段。把本文提到的8个问题一个一个吃透再往下延伸到集合、并发、JVM你的Java知识体系会越来越完整。基础这东西没有捷径但绝对值得投入。我的建议是把这篇文章收藏起来每周抽一个晚上挑一个知识点用代码写一遍再用自己的话讲一遍。坚持两个月你再回来看这些Java基础题心态会完全不一样。学基础慢就是快。