兄弟们做Java开发的有句话叫“根基不牢地动山摇”。很多工作两三年的朋友写业务代码溜得飞起但一问到Java常用类的底层设计、经典坑点反而支支吾吾。尤其是面试时候面试官最爱从“你平时用过哪些常用类”切入一路追问到String、包装类、集合的底层原理这些都是拉开差距的地方。这篇东西我结合自己这些年的项目经验和带新人的心得把Java里最核心、最高频的常用类系统梳理一遍。不讲虚的直接上干货适合正在学Java基础的朋友也适合准备跳槽想复盘一轮的老手。1. 先从老祖宗Object说起1.1 所有类的根equals和hashCode的约定Object是Java所有类的父类这个大家都知道但真正理解它设计意图的人不多。它里面有十几个方法日常开发中最常打交道的就是equals、hashCode、toString这三个。先说equals。默认的Object.equals比较的是内存地址也就是“是不是同一个对象”。但在业务开发里我们关心的往往是“两个对象的内容是否相等”。比如一个User对象只要userId相同我们就认为是同一个用户。这时候就需要重写equals。但重写equals有个铁律重写equals必须同时重写hashCode。为什么因为Java里很多集合类比如HashMap、HashSet都依赖hashCode先定位存储位置再用equals确认是否相等。如果你只重写equals不重写hashCode会导致两个内容相同的对象hashCode不同HashMap就可能把一个逻辑上相同的对象存进两个不同的桶里出现重复数据甚至get的时候找不到。这个坑我在实际项目里见过不止一次。hashCode的约定有三个两个对象equals相等hashCode必须相等两个对象hashCode相等equals不一定相等哈希碰撞同一个对象多次调用hashCode结果必须一致。实操建议用IDE自动生成的equals和hashCode基于关键业务字段就好比手写靠谱千万别自己拍脑袋写hash算法容易引入性能问题。1.2 toString和finalize的实际使用toString应该是Object里最“好用”的方法了。默认实现是“类名十六进制哈希值”这玩意儿在排查问题时候基本没法看。所以我习惯在实体类里重写toString把核心字段打出来。这样在日志里看到的不再是com.demo.User1a2b3c4而是User{id1, name张三, age18}排查线上问题效率直接翻倍。finalize这方法现在基本属于“遗弃”状态了。它是在对象被垃圾回收前调用的钩子但JVM不保证它一定会执行也不保证执行顺序用它来做资源释放完全是给自己挖坑。Java 9开始已经标记为废弃了。我的观点就一句话别碰finalize资源释放请用try-with-resources或者finally块。另外还有两个经常被忽略的方法getClass和clone。getClass配合反射用的场景多比如动态判断实例类型。clone是浅拷贝只有实现了Cloneable接口才能调用但它“违反直觉”的地方在于浅拷贝出来的对象引用类型的成员变量还是指向同一个对象。所以实际开发里我更推荐用构造函数拷贝、或者直接转JSON再转回来这种方案比clone可控得多。2. String类Java里最特殊的“基本类型”2.1 不可变性的底层逻辑Java程序员几乎每天都在用String但很多人没想过一个问题为什么String要被设计成不可变的这是面试高频题同时也是理解JVM内存模型的一个非常好的切入点。String的不可变体现在它内部用final修饰的char数组JDK9开始改成byte数组存储字符类本身也是final的不允许被继承。所有看似修改字符串的操作比如concat、replace、substring实际上都是返回了一个新对象原对象纹丝不动。这个设计的价值线程安全不可变对象天然线程安全可以被多个线程共享不需要加锁字符串常量池正因为不可变JVM才能放心地把相同的字符串字面量放在常量池里共享避免重复创建对象浪费内存哈希缓存String的hashCode在第一次计算后会被缓存起来因为它不可变所以这个缓存永远有效HashMap用String做key效率很高。我遇到过有不少人背了“String不可变”这句话却不知道它对应的场景意义。面试时如果能从线程安全和常量池这两个点回答就比单纯背结论高一个档次。2.2 常量池与new String(abc)的区别这是Java基础面试必考的一道经典题。String a abc和String b new String(abc)有什么区别答案分两层。第一层“abc”这个字面量在类加载阶段就会被放进字符串常量池a直接引用常量池里的对象不会在堆里额外创建对象。而new String(abc)强制在堆里创建一个新对象然后这个新对象的value又指向常量池里的字面量。画个简单的内存逻辑常量池里有一个abc堆里有一个独立的String对象b引用的是堆对象a引用的是常量池对象。所以a b返回false因为用比较的是引用地址不是内容。那a abc呢返回true因为a引用的就是常量池里的那个abc。b.equals(abc)返回true因为equals比较内容。还有个容易踩坑的字符串的拼接如果两个都是字面量比如a b编译器会直接在编译期就优化成ab也就是说它也指向常量池。但如果有一个是变量比如String c a; String d c b;这个拼接在运行期是通过StringBuilder完成的d指向堆里新建的对象。所以d ab是falsed.intern() ab才是true。2.3 StringBuilder和StringBuffer怎么选既然String不可变那可变的字符串类就有用武之地了。StringBuilder和StringBuffer的API几乎一模一样唯一区别是StringBuffer的方法加了synchronized关键字线程安全。线程安全听着“高大上”但同步是有性能开销的。在绝大多数业务场景下字符串拼接发生在方法内部不会跨线程共享变量这时候用StringBuffer完全没必要。所以我的建议很简单默认用StringBuilder只有明确要作为成员变量被多线程共用时才用StringBuffer。这里还有个性能大坑要提醒不要在循环里用拼接字符串。比如往一个List里的数据拼SQL的IN语句String sql SELECT * FROM user WHERE id IN (; for (Long id : idList) { sql id ,; }每次都会创建一个新的String对象循环1000次就是创建1000个对象还会伴随多次数组拷贝性能惨不忍睹。正确姿势是先StringBuilder sb new StringBuilder()循环里sb.append(id).append(,)最后一次性sb.toString()。JDK9以后单个的“字面量变量”表达式编译器会自动转换成StringBuilder操作这是编译器的优化但循环体内是多次独立的拼接表达式编译器没法跨迭代优化坑仍然在。3. 包装类自动装箱拆箱的甜蜜陷阱3.1 Integer缓存的经典面试题Java的类型体系里基本类型和对象之间有个桥梁——包装类。int对应Integerlong对应Longboolean对应Boolean。有了自动装箱拆箱代码里可以Integer i 100; int j i;编译器自动完成转换。但这个转换背后有不少隐藏逻辑。看一个经典题目Integer a 100; Integer b 100; System.out.println(a b); // true Integer c 200; Integer d 200; System.out.println(c d); // false答案是第一个true第二个false。原因是Integer内部有个缓存机制valueOf方法在取值-128到127之间的整数时会直接返回缓存数组里的同一个对象。所以a和b指向的是缓存里的同一个对象比较引用当然相等。而200超出了缓存范围valueOf会new一个新的Integer对象c和 d是不同的引用所以返回false。这个缓存范围在Java 6之前是写死的-128到127Java 6开始可以通过JVM参数调整上限。实践中我不建议大家去调这个参数知道就行。避免这套坑的办法包装类型比较一律用equals别用。这也是阿里Java开发手册里明确要求的。同理所有包装类的比较都要遵循这个原则。3.2 包装类在泛型和集合里的必要性基本类型不能用在泛型里这是包装类存在的一个重要原因。比如ListInteger你不能写成Listint。因为泛型在编译期会被类型擦除底层需要的是Object类型基本类型无法完成这个转换。集合框架存储的元素必须是对象——LinkedList的节点、HashMap的键值这些内部结构只能引用对象。所以往集合里放数字时int会自动装箱成Integer从集合里取出来时Integer自动拆箱成int。这个过程表层代码看不到但字节码里清清楚楚写着Integer.valueOf和intValue的调用。由此引发的空指针是最常见的包装类坑。比如MapString, Integer map new HashMap(); int num map.get(key); // 如果key不存在get返回null拆箱瞬间抛NPE这里map.get返回的是null赋值给int的时候要拆箱拆箱调用intValue对null调用方法——空指针。我在代码审查里见这类问题太多了。养成习惯从集合或对象里取包装类赋值给基本类型之前一定要判空。3.3 数值比较的“感觉差不多”不等于“相等”还有一个很容易被忽略的点包装类作为JavaBean属性时默认值是null不是0。比如一个Integer类型的年龄字段用户没填时它是null如果直接参与算术运算就会NPE。而基本类型int的默认值是0两者语义完全不同。数据库字段允许为NULL时对应Java实体类字段选包装类不允许为空时可以用基本类型不要混淆。这个选择不光是“省不省内存”的问题而是直接关系到数据语义的准确性。4. 日期时间类从Date一路到LocalDateTime4.1 SimpleDateFormat的线程安全问题早期的Java日期API是java.util.Date和java.util.Calendar配合java.text.SimpleDateFormat做格式化。这玩意儿三个字总结不好用。月份从0开始计0代表1月年份偏移1900很多刚入行的朋友第一次用new Date(2024, 0, 1)建日期时看到输出2024年1月1日松了口气却不知道这构造函数已经废弃了内部还帮你把年减了1900。而SimpleDateFormat更坑它内部维护了一个Calendar对象format和parse方法不是线程安全的。当多个线程共享同一个SimpleDateFormat实例时会出现解析结果错乱甚至JVM崩溃。我早年在一家金融公司线上系统有个定时任务每天晚上用同一个SimpleDateFormat格式化时间戳后写文件某天突然有几个数据时间错了排查了半天才发现是并发调用导致Calendar内部状态被污染。后来统一用ThreadLocal包了一层或者干脆用LocalDateTime替代问题根除了。4.2 新时间API的正确使用方式Java 8开始引入了java.time包这个设计确实优秀。核心类是LocalDate日期、LocalTime时间、LocalDateTime日期时间、ZonedDateTime带时区和Instant时间戳。这套API的设计理念是“不可变线程安全”所有方法都返回新对象不会修改旧对象。命名也非常规范of用来创建实例plus做加法minus做减法with做调整format用DateTimeFormatter格式化parse从字符串解析。我自己写代码的经验是数据库存储时间推荐用TIMESTAMPJava侧对应LocalDateTimeMyBatis-Plus等框架都能自动转换跨时区系统用Instant或ZonedDateTime与UTC对比时才不会有偏差前端传字符串时间用LocalDateTime.parse时注意默认格式是2024-01-01T10:00:00带了字母T和常用格式不同一般要配合DateTimeFormatter自定义格式比如DateTimeFormatter fmt DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); LocalDateTime time LocalDateTime.parse(2024-06-01 12:30:00, fmt);4.3 日期计算和格式化的实操细节做日期计算时新API的链式写法非常舒服。比如计算30天前的日期LocalDate today LocalDate.now(); LocalDate thirtyDaysAgo today.minusDays(30);计算两个日期差多少天long days ChronoUnit.DAYS.between(startDate, endDate);需要把日期格式化成字符串String str today.format(DateTimeFormatter.ofPattern(yyyy年MM月dd日));这里有几个习惯要养成判断日期间隔时两个时间点统一用Instant做比较不要在LocalDateTime之间直接做大小比较因为LocalDateTime不带时区信息跨时区场景会出错每个月最后一天用YearMonth来算不要自己判断月份是大是小更稳妥YearMonth month YearMonth.of(2024, 2); LocalDate lastDay month.atEndOfMonth();5. 集合框架里的高频常用类5.1 ArrayList和LinkedList的真实差异聊到集合框架ArrayList和LinkedList是出场率最高的两个。很多教科书上说“ArrayList查询快、增删慢LinkedList增删快、查询慢”这话有误导性。真相是ArrayList基于动态数组随机访问是O(1)但指定位置插入或删除需要移动后续元素尾部插入最省事LinkedList基于双向链表头部插入删除是O(1)但随机访问是O(n)哪怕get(500)也要从链头开始找过去链表每个节点还要多存前后指针内存开销比ArrayList一个连续数组大得多。更反直觉的是如果做中间插入比如在列表正中间插一个元素LinkedList虽然定位到了那个位置但插入本身还是需要改动前后节点的引用而ArrayList要搬运后半段元素——测试下来数据量上万时ArrayList反而常常比LinkedList更快因为连续内存搬运的效率实在太高了而链表节点的新建和指针操作开销不小。所以现代实践基本形成了共识绝大多数场景用ArrayList就好。LinkedList的真正优势场景是“队列两端的频繁插入删除”比如实现了Deque接口做双端队列用但这种情况直接用ArrayDeque更合适。5.2 HashMap的底层机制与扩容策略HashMap可能是Java里最常用的键值对容器也是面试重灾区。它底层是“数组链表红黑树”结构根据key的hashCode计算桶下标哈希碰撞后用链表或树拖链解决。几个关键参数默认初始容量16默认负载因子0.75链表长度超过8且数组长度超过64时链表升级为红黑树树退化回链表的阈值是6留了缓冲防止元素在边界频繁增删导致反复转换。为什么负载因子是0.75这是时间与空间的折中。负载因子越大空间利用率越高但哈希碰撞概率增大查询效率下降负载因子越小空间浪费越多但查询效率高。0.75这个值在数学统计上泊松分布模型能把链表长度超过8的概率压得非常低所以这个参数设计是有统计学依据的。扩容机制当size超过容量×负载因子16×0.7512时容量扩大为原来的两倍然后重新计算每个元素的位置这个过程叫rehash。JDK8对扩容做了优化元素的位置要么在原下标要么在原下标旧容量判断依据是key的hash值新增的那一位是0还是1省去了从零重新计算hash的过程。日常开发要注意的千万别用可变对象做HashMap的key。如果key的hashCode依赖的字段被修改了HashMap再get这个key时计算出来的新桶位和原来存放的位置对不上就找不到数据了。如果非要用后果自负——这是Google Java规范里也点名提示过的。5.3 HashSet和TreeSet的选型思路HashSet底层就是个HashMapvalue是固定的PRESENT常量去重靠的就是HashMap的key唯一性。所以重写equals和hashCode的正确性在HashSet里格外重要——去重判断先走hashCode定位再走equals确认。TreeSet底层是红黑树元素有序要么实现Comparable接口要么传入Comparator比较器。它适合需要有序遍历的场景比如按分数从低到高输出玩家排名。但插入和删除的时间复杂度是O(logn)比HashSet的O(1)要慢。所以纯去重用HashSet需要排序才选TreeSet。顺便说一句很多面试题里喜欢问“HashSet怎么实现去重”。标准回答就是结合HashMap key不可重复的机制来论述这要求你理解HashMap的put过程先算hash找桶桶里没元素直接放桶里有元素再逐个equals比较有相等的新值覆盖旧值返回旧值。HashSet往HashMap里put(k, PRESENT)时如果返回的旧值不是null说明key已经存在就“去重失败”set里不添加。6. 工具类写业务代码的加速器6.1 Arrays和Collections这对黄金搭档Arrays是数组的操作工具类排序用Arrays.sort()二分查找用Arrays.binarySearch()数组转列表用Arrays.asList()数组拷贝用Arrays.copyOf()和System.arraycopy()这是底层方法。这些方法里有一个反直觉的坑Arrays.asList()返回的列表不能增删元素。它返回的是一个Arrays内部类ArrayList注意不是java.util.ArrayList这个内部类的数组是定长的调add或remove会直接抛UnsupportedOperationException。这个设计是为了保留数组定长特性但很多人第一次用都会踩这个坑。如果需要真正可以增删的Listnew ArrayList(Arrays.asList(arr))套一层就好。Collections工具类针对集合操作Collections.sort()排序传List和ComparatorCollections.reverse()反转Collections.shuffle()打乱Collections.unmodifiableList()把一个可变集合包装成不可变集合Collections.synchronizedList()包装成线程安全集合。这里有个经验unmodifiableXxx包装出来的集合只禁止通过包装之后的引用修改集合如果原集合引用还在可变仍然可以改。要保证绝对不可变要么彻底不暴露原引用要么用Java 9之后的List.of()、Set.of()创建真正的不可变集合。6.2 Objects工具类避免空指针折磨Objects类是Java 7引入的专治各种空指针。写代码时最常用的Objects.equals(a, b)做了null安全的比较a和b都可以是null不会NPEObjects.requireNonNull(obj)校验obj不为null为null就抛NPE常用于方法入参校验Objects.hashCode(obj)null安全的hashCode是null返回0Objects.toString(obj)null安全的toString。我记得有个老项目里大量代码写的是if (user ! null user.getName() ! null user.getName().equals(admin))三层判空。如果改成Objects.equals(user.getName(), admin)并且在入口用requireNonNull卡掉不可能的null代码会干净很多。每少一个if嵌套可读性就好一分。6.3 Math类和其他零散工具类Math类提供了一堆静态方法Math.max/min、Math.abs、Math.pow、Math.sqrt、Math.random()0.0到1.0的随机数注意左闭右开。还有Math.floor和Math.ceil。需要注意Math.abs(Integer.MIN_VALUE)返回的仍然是负数因为整数溢出了这种边界条件测试时容易忽略。按需使用的还有UUID生成随机唯一IDUUID.randomUUID().toString()做分布式系统里的数据库主键、traceId特别好用BigDecimal做金钱运算浮点数用double直接算加减乘除会出现精度问题金钱场景必须用BigDecimal初始化最好用字符串构造器new BigDecimal(0.1)不要用new BigDecimal(0.1)。7. 面试高频题与日常避坑速查7.1 高频面试题整理问题关键考点一句话解法String为什么不可变线程安全、常量池共享、hash缓存内部value是final byte数组类本身finalString、StringBuilder、StringBuffer区别不可变/可变、线程安全默认StringBuilder共享场景用StringBuffer和equals区别引用比较/内容比较Object.equals比较引用重写后比较内容重写equals必须重写hashCode集合去重依赖HashMap/HashSet先比hashCode再比equalsInteger缓存范围自动装箱的valueOf缓存-128到127之间返回缓存对象HashMap底层结构数组链表红黑树负载因子0.75链表超8转树ArrayList和LinkedList怎么选随机访问/两端操作无特殊理由选ArrayListSimpleDateFormat线程安全Calendar状态污染用LocalDateTime或ThreadLocal包一层BigDecimal精度double无法精确表达用String构造BigDecimal不直接用doubleArrays.asList能否增删定长数组包装返回内部类ArrayList增删抛异常7.2 开发中遇到的经典Bug复盘复盘我经历的几次事故都是因为“对常用类只知API不知原理”。第一起是并发环境下时间格式化错乱。线上服务多个线程共用一个SimpleDateFormat实例某天批量任务解析用户生日时部分记录变成了前一天甚至差了好几年。原因前面说过了SimpleDateFormat里的Calendar是共享可变状态。后来不只换了LocalDateTime还顺手排查了一遍代码库里所有SimpleDateFormat的使用点。第二起是HashMap并发扩容死循环。JDK7时代HashMap并发put会导致扩容时形成环形链表get时死循环CPU飙满。JDK8修了这个问题但并发下的数据丢失问题仍然存在多线程put会导致size统计不准确。现在规范一律要求并发场景用ConcurrentHashMap别再拿HashMap硬扛多线程了。第三起是整数溢出。有一次计算一批商品的折扣总额逻辑是discount * price / 100其中discount和price都是int。某次算大额订单时discount * price超过了int的最大值2147483647变成了负数总价计算直接崩了。这种用int做乘法运算的操作哪怕结果看起来不会超范围中间过程也可能溢出。钱相关计算一律BigDecimal或者至少保证中间结果是long。7.3 我的日常编码检查清单这些坑踩多了我现在写代码有一套自己的检查清单包装类比较一律equals绝不用集合、Map里取出来的包装类赋值给基本类型先判空循环拼接字符串用StringBuilder不在循环体内用日期格式化不用SimpleDateFormat用DateTimeFormatter键值对存储优先考虑HashMap并发才用ConcurrentHashMap数组转List要能增删用new ArrayList(Arrays.asList(arr))金钱计算从字符串构造BigDecimal不用double直接做运算实体类里覆写toString生产环境排查问题省事。8. 学习路径建议和资料推荐8.1 怎么把这些类学到能用的程度很多初学者有个误区把Java常用类的API文档从头到尾背一遍然后发现写代码还是啥都不会。正确思路是以问题为驱动去学。比如你先写一个小工具——解析一份CSV文件按某列排序去重统计各分类数量导出到Excel。这个过程中你自然要用到BufferedReader、ArrayList、HashMap、TreeSet、Comparator、LocalDateTime这些类和接口用起来了API自然就记住了。另一个好办法是“读源码”。不用把JDK源码全读一遍但ArrayList的扩容逻辑、StringBuilder的append流程、HashMap的put方法、Integer的缓存实现这四段源码值得精读。读源码不是为了背代码而是理解设计者面临什么问题、为什么这么解决。比如Integer缓存读valueOf方法的那一刻你就明白了为什么Integer i 127和i 128行为不一样。这些理解面试官一问就能感受出来是“真懂”还是“背过”。8.2 推荐几个沉淀方向Java常用类背后牵涉的知识面很广内存模型、集合源码、并发机制、设计模式。我建议按“广度了解-深度精通”两步走。第一轮先把上面讲的类和API都用熟能独立写出可运行的程序第二轮针对集合和并发细读源码搞明白底层实现。到那个时候你已经不是“会用”Java而是“懂”Java了。如果时间紧张至少把String、包装类、集合框架、日期时间、BigDecimal这五块吃透。它们覆盖了线上Java服务90%以上的日常开发需求也是面试官最爱的提问领域。把这篇里的原理和坑点消化掉基础这一关就问题不大了。