搞Java这么多年我一直觉得“常用API”是最容易被忽视、但又最值得反复咀嚼的一块内容。刚入行那会儿我也觉得API不就是查文档嘛用的时候翻一下就行。可真到面试、接手老项目、或者自己搭一套代码的时候才发现真正拉开差距的往往就是你对这些常用类的底层原理、线程安全性、性能特性理解得有多深。比如同样处理字符串有人习惯直接拼“”号有人会用StringBuilder还有人能说出JVM在编译期做了什么优化——这背后就是经验的分水岭。这篇文章我系统梳理一下Java开发中最常用、也是面试最高频的那批APIString体系的不可变设计与字符串拼接优化、集合框架的选型逻辑与排序、日期时间API的线程安全陷阱、还有Stream和Lambda这种现代写法。每一个主题我都会把原理讲透再配上我在实际项目里踩过的坑和验证过的结论。不管你是准备面试还是想把自己的代码写得更稳这篇都能直接拿去用。1. String、StringBuilder与StringBuffer文本处理的第一课1.1 String的不可变性到底意味着什么String是Java里最特殊的类没有之一。它被final修饰底层用private final byte[] value存储字符JDK 9之后从char[]改成了byte[]主要为了节省内存。这个final不是摆设它保证了String对象一旦创建内容就永远不变。这个不可变性带来三个直接好处字符串常量池可以安全复用多个变量指向同一个字符串字面量时不会互相干扰。多线程环境下String天然线程安全不需要任何同步措施。hashCode可以缓存因为内容不会变hash值算一次就够了这也是String适合做HashMap key的原因。但代价也很明显每次对String做拼接、替换、截取本质都是创建新对象。比如String s a b c如果出现在循环里会不断产生中间垃圾对象给GC造成压力。我在实际项目中见过一个性能事故一个大盘数据导出功能用“”号在for循环里拼了2万条JSON字符串结果接口响应时间从200ms飙升到8秒。排查到根因后改成StringBuilder直接降到300ms。这就是不可变性在真实场景里的威力。1.2 字符串拼接的性能分水岭编译期优化与运行时拼接我们先说结论在单线程下拼接字符串优先用StringBuilder在多线程共享可变字符串才考虑StringBuffer单纯几个字面量拼接直接写“”号编译器会帮你优化。很多人对“”号有误解觉得它性能差。其实分两种情况第一种编译期就能确定的字符串常量拼接。比如String s Hello Worldjavac在编译时就直接算好结果字节码里就是一个完整的字符串常量不存在运行时拼接开销。这种写法完全没问题。第二种运行期才能确定的拼接。比如变量参与、或者在循环里拼接编译器会把连续拼接优化成new StringBuilder().append()的调用链。但注意如果拼接发生在循环体内每次循环都会new一个StringBuilder这个开销就不可忽略了。StringBuffer和StringBuilder的区别一句话就能说清StringBuffer的方法加了synchronized关键字线程安全但性能差StringBuilder没有加锁单线程下性能更高。现代Java开发中StringBuffer基本没有使用场景了因为需要线程安全的可变字符串时更好的方案是采用局部变量加StringBuilder从根上避免共享可变状态。1.3 面试高频equals与hashCode的关系String的equals比较的是字符内容这是常识。但面试官经常会追问一句为什么重写equals必须重写hashCode这就要回到HashMap的存储原理了。HashMap put的时候先用key的hashCode定位桶再在桶内用equals判断是否存在相同key。如果两个对象equals相等内容相同但hashCode不同就会散落到不同桶里导致HashMap里出现两个“相等”的key这违反Map的语义约束。反过来hashCode相同但equals不等哈希碰撞是允许的让它们在同一桶里用链表或红黑树处理就行。String已经正确重写了这两个方法所以我们日常用String做key不会有问题。但这个考点真正想考察的是你有没有理解自定义对象作为Map key时的注意事项。我见过有人用不含业务字段的对象做key导致每次查到同一个值却判断key不存在排查了半天才发现hashCode没重写。2. 集合框架选型决定性能上限2.1 List、Set、Map的底层实现与适用场景集合框架是Java API里最庞大也最常用的一块。我按照“底层数据结构→适合场景→注意事项”的思路把最常用的几个实现类过一遍。ArrayList底层是Object[]数组默认容量10扩容时按1.5倍增长新容量旧容量旧容量右移一位。查询快O(1)插入删除慢需要移动元素O(n)尾插快。单线程开发首选几乎没有争议。LinkedList底层是双向链表插入删除快O(1)只要已定位到节点但随机访问慢O(n)。说实话在现在的硬件条件下LinkedList的很多优势都被ArrayList的CPU缓存友好性抵消了实际项目里我很少主动用LinkedList。如果你需要频繁在头部插入删除可以用ArrayDeque性能比LinkedList好得多。HashSet底层是HashMap值存在key上value固定为同一个Object。去重场景常用但注意HashSet不保证迭代顺序。如果需要按插入顺序遍历用LinkedHashSet如果需要排序用TreeSet。HashMap核心中的核心。JDK 8之后底层是数组链表红黑树链表长度超过8且数组长度超过64时转红黑树。默认负载因子0.75这个值同时兼顾了空间利用率和查询效率的平衡。扩容是翻倍扩容代价是rehash。迭代顺序不保证稳定不要依赖。TreeMap底层红黑树key按自然顺序或Comparator排序支持范围查询。如果需要按key有序遍历TreeMap是唯一选择时间复杂度O(log n)。Hashtable整个类都被锁住性能差JDK官方都推荐用ConcurrentHashMap替代。面试时问它主要考察你对旧代码的认知。2.2 排序逻辑Comparable与Comparator的正确用法排序是集合操作里绕不开的点。Java提供了两个排序接口很容易混淆我一次说清。Comparable接口定义在实体类内部表示“这个类天生具备可比性”。实现它的类需要重写compareTo(T o)方法返回负数、零、正数分别表示this小于、等于、大于o。比如Integer实现了Comparable所以List 可以直接Collections.sort。Comparator接口定义在外部表示“为某个类提供一种排序策略”。它的核心方法是compare(T o1, T o2)。好处是不需要修改实体类源码可以在不同场景下定义不同的排序规则还可以用链式调用组合多个排序条件。JDK 8之后日常开发中Comparator用得更频繁。因为Lambda表达式可以轻松创建Comparator// 按年龄升序年龄相同按姓名降序 list.sort(Comparator.comparing(User::getAge) .thenComparing(Comparator.comparing(User::getName).reversed()));这里有个实战坑reversed()作用于它前面的整个Comparator链。比如上面的写法reversed()只作用于name的Comparator不是把整个链表反转。如果你想反转整个排序结果应该写成list.sort(Comparator.comparing(User::getAge).thenComparing(User::getName).reversed())把reversed()挂在最外层。2.3 排序算法的隐藏考点冒泡排序与快速排序的工程选择热搜词里出现了“冒泡排序java”和“快速排序java实现”我顺便聊聊。面试考排序算法核心不是让你背代码而是考察你对算法复杂度和工程选择的认知。冒泡排序时间复杂度O(n²)空间复杂度O(1)。它的特点是稳定、代码简单、对小规模数据友好。但n超过1000之后性能就很拉胯了。我把冒泡排序写出来因为它的双循环结构是理解其他排序的基础public void bubbleSort(int[] arr) { int n arr.length; for (int i 0; i n - 1; i) { boolean swapped false; for (int j 0; j n - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; swapped true; } } if (!swapped) { break; // 没有发生交换说明已经有序提前退出 } } }这个带swapped标记的版本就是优化过的最好情况下已有序数组时间复杂度降到O(n)。快速排序是工程上使用最广泛的排序算法平均时间复杂度O(n log n)但不稳定。JDK的Arrays.sort对基本类型数组用的是DualPivotQuicksort双轴快排对对象数组用的是TimSort。为什么基本类型和对象用不同算法因为基本类型不需要稳定排序快排更高效对象排序需要保证稳定性相等元素顺序不变TimSort更合适。这个细节面试时很容易被问到。实际开发中我们需要排序时直接用Arrays.sort()或list.sort()就行了JDK内置的排序算法经过大量优化性能远超自己手写。但理解冒泡和快排的原理能帮你在面试中展现扎实的基本功也能让你理解JDK为什么这样做选择。3. 日期时间API从java.util.Date到java.time3.1 SimpleDateFormat的线程安全陷阱老一代日期APIjava.util.Date、java.util.Calendar、java.text.SimpleDateFormat有个经典大坑SimpleDateFormat不是线程安全的。它的format和parse方法内部会修改一个Calendar类型的成员变量用来暂存日期字段。多线程并发调用时一个线程正在格式化过程中改了calendar的状态另一个线程也来读写同一个calendar就会导致格式错乱甚至抛出ArrayIndexOutOfBoundsException或NumberFormatException。我当年踩过一次一个定时任务每分钟格式化一次时间戳写入日志上线后偶发报错日志时间还出现过1970年这种离谱值。排查了半天最后定位到是SimpleDateFormat被声明成了static共享实例。解决方案有三种每次使用时new新实例低并发下简单有效使用ThreadLocal每个线程持有独立实例或者直接用DateTimeFormatter这是JDK 8引入的线程安全的。这里多说一句很多人以为用了ThreadLocal就万事大吉但忘了在不需要时调用remove()清理。在Tomcat这类线程池环境下线程不会销毁ThreadLocal里的SimpleDateFormat实例会一直存活如果还持有其他大对象引用极易引发内存泄漏。3.2 LocalDateTime与DateTimeFormatter的正确打开方式JDK 8引入的java.time包设计上全面碾压旧API。核心类包括LocalDate日期、LocalTime时间、LocalDateTime日期时间、Instant时间戳、Duration时间段、Period日期间隔、ZoneId时区和DateTimeFormatter格式化。这套API的核心设计理念是不可变性所有修改操作都返回新对象原对象不变。所以它是天然线程安全的根本不需要担心并发问题。常用的操作套路我列几个// 获取当前时间 LocalDateTime now LocalDateTime.now(); // 字符串转LocalDateTime注意格式要匹配 DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); LocalDateTime parsed LocalDateTime.parse(2024-12-08 14:30:00, formatter); // LocalDateTime转字符串 String text now.format(formatter); // 日期运算 LocalDateTime tomorrow now.plusDays(1); LocalDateTime firstDayOfMonth now.withDayOfMonth(1);对比一下新旧API的转换方式老代码里dateFormat.parse(str)会抛出受检异常ParseException调用方必须处理而DateTimeFormatter的parse返回LocalDateTime不强制抛受检异常代码清爽得多。还有一点值得注意LocalDateTime.now()默认使用系统默认时区在服务器和客户端时区不一致时会造成时间偏差。分布式系统里统一使用UTC时间存储展示层再转本地时区是行业惯例。Instant.now()获取的就是UTC时间戳适合做数据库存储字段。3.3 时间计算与格式化实战中的边界问题日期处理最头疼的是各种边界情况。比如月末、闰年、夏令时一旦不留意就会算错。我举几个实际经验加一个月LocalDate.of(2024, 1, 31).plusMonths(1)结果是2024-02-29因为2024年是闰年。如果那年不是闰年结果是2月28日。这是合理的语义但业务上要明确这是不是你要的效果。计算年龄不要直接用Period.between(birthDate, today).getYears()它算的是整年数。比如2000-12-31出生的人在2024-01-01时Period算出来是23岁因为还没到生日。这在某些业务场景下不够精确需要按需求调整。时间戳精度MySQL的datetime类型默认精确到秒如果在Java里用了LocalDateTime.now()存入毫秒会被截断。如果业务需要毫秒级精度数据库字段要用datetime(3)或bigint存毫秒数。格式化的坑主要是模式字母大小写容易混淆yyyy是年份MM是月份dd是日期HH是24小时制小时hh是12小时制小时mm是分钟ss是秒。一个常见的低级错误是用yyyy-mmm-dd结果解析失败。Debug时看到DateTimeParseException先检查格式串字母大小写能省一半排查时间。4. 常用工具类与函数式编程让代码更简洁4.1 Arrays与Collections被低估的效率工具Java的java.util.Arrays和java.util.Collections是两个工具类全部由静态方法组成日常开发使用频率极高。但很多人只会用其中两三个方法实在可惜。Arrays的常用方法// 数组转List注意返回的是定长List不能add/remove ListString list Arrays.asList(a, b, c); // 数组排序 int[] arr {3, 1, 2}; Arrays.sort(arr); // 二分查找先排序再查 int index Arrays.binarySearch(arr, 2); // 打印数组 System.out.println(Arrays.toString(arr)); // 数组拷贝扩容常用 int[] newArr Arrays.copyOf(arr, arr.length * 2);这里有个高频坑Arrays.asList返回的List底层还是那个数组所以调用add或remove会抛UnsupportedOperationException。业务代码里如果后续要增删元素应该new ArrayList(Arrays.asList(...))包一层。还有一个容易忽略的Arrays.asList(int[])处理基本类型数组时不按你想的来。因为泛型只能接收引用类型int[]被当成一个整体对象返回的List泛型是int[]而不是Integer。结果是List里只有一个元素还是个数组对象。正确做法是Arrays.stream(arr).boxed().collect(Collectors.toList())。Collections的常用方法// 排序 Collections.sort(list); // 反转 Collections.reverse(list); // 线程安全包装 ListString safeList Collections.synchronizedList(new ArrayList()); // 不可变集合 MapString, String map Collections.unmodifiableMap(new HashMap());不可变集合在多线程环境下很有价值不需要加锁即可安全共享。JDK 9之后可以用List.of()、Map.of()更简洁地创建不可变集合这是新项目的首选。4.2 Lambda表达式与Stream API从外部迭代到内部迭代Lambda表达式的本质是函数式接口的简写。函数式接口就是只有一个抽象方法的接口比如Comparator、Runnable、Callable。JDK 8在java.util.function包里提供了一批通用函数式接口FunctionT,R输入T返回R、Consumer 输入T无返回、Supplier 无输入返回T、Predicate 输入T返回boolean。理解Lambda的关键是“行为参数化”把代码逻辑作为参数传给方法。以前写排序需要new一个匿名内部类现在一行Lambda搞定// 旧写法 Collections.sort(users, new ComparatorUser() { Override public int compare(User u1, User u2) { return u1.getAge() - u2.getAge(); } }); // Lambda写法 users.sort((u1, u2) - u1.getAge() - u2.getAge());Stream API是配合Lambda最核心的API。它的操作分两类中间操作返回新Stream惰性执行和终端操作触发计算产生结果。常用中间操作有filter、map、sorted、distinct、limit、skip常用终端操作有collect、forEach、reduce、count、anyMatch、allMatch、noneMatch。我把实际项目里最常用的一段Stream操作写出来去重、过滤、排序、提取字段、转Map一次搞定ListUser result users.stream() .filter(u - u.getStatus() 1) // 过滤状态 .distinct() // 按equals去重 .sorted(Comparator.comparing(User::getAge)) // 按年龄排序 .limit(10) // 取前10条 .collect(Collectors.toList()); // 收集成ListStream的惰性求值机制值得注意中间操作不会立即执行而是等到终端操作触发时才一次性处理。这个设计让Stream可以优化执行计划比如limit(10)配合sorted时JDK内部能做短路优化不用完整排序所有元素。但副作用是如果有人在中间操作里修改变量容易踩到“没执行”的坑。4.3 实战用Stream重构一段过程式代码纸上谈兵没意思我拿一个真实的例子说明Stream如何简化代码。假设有一个订单列表需要做如下处理过滤掉金额小于100的订单按金额降序排序提取订单号拼接成逗号分隔的字符串。过程式写法ListString highValueOrderIds new ArrayList(); for (Order order : orders) { if (order.getAmount() 100) { highValueOrderIds.add(order.getOrderId()); } } highValueOrderIds.sort((o1, o2) - { // 这里需要先找到对应订单再比较金额或者额外维护一个Map return 0; }); String result String.join(,, highValueOrderIds);Stream写法String result orders.stream() .filter(o - o.getAmount() 100) .sorted(Comparator.comparing(Order::getAmount).reversed()) .map(Order::getOrderId) .collect(Collectors.joining(,));清晰度差异一眼可见。更重要的是Stream的链式调用让每个环节独立可测改一个条件不会影响其他逻辑。这种声明式写法在集合多级处理、批量转换、报表统计场景下代码量能砍掉一半以上。但Stream不是万能药。三层以上的嵌套stream操作可读性反而下降循环体里有复杂业务逻辑需要多个外部变量交互时普通for循环更直观大数据量下Stream的lambda调用也会增加少许开销。工程上我的习惯是单层集合处理用Stream复杂业务逻辑用传统循环两者并存别走极端。5. 常见问题与排查技巧实录5.1 编译报错源发行版17需要目标发行版17这个报错在热搜词里出现了我猜八成是刚升级JDK版本或者导入新项目时遇到的。这个报错的意思是javac编译时-source参数指定了17但-target或-bootclasspath指定的版本不一致。产生原因几乎都是IDE的Project Structure里Project SDK和Project language level设置不匹配。比如SDK选的是JDK 17但language level还停留在11或者Maven的maven-compiler-plugin里source和target设置不一致。排查步骤很简单先检查Project Structure里Project SDK和Project language level是否一致再检查pom.xml或build.gradle里Java版本配置确保source、target、release三个参数统一最稳妥的做法是设置release17/release它会同时覆盖source和target的约束省得忘了维护两个参数。另一个常见来源是Lombok。热搜词里有“java: you arent using a compiler supported by lombok, so lombok will not wo”这个通常是Lombok版本太老不支持当前JDK版本。Lombok 1.18.20之前的版本不支持JDK 16以上的record和某些新特性解决方案就是升级Lombok版本Java 17对应Lombok 1.18.30。5.2 运行时OutOfMemoryError: Insufficient Memory这个错误比普通OOM更让人抓狂因为它是JVM层面的“无内存可用”。可能原因有两种进程可用内存本身就小于JVM启动参数要求的最小堆或者操作系统内存被其他进程耗尽。我见过一个典型场景Docker容器里设置了JVM参数-Xmx4g但容器本身memory limit只给了2g。Java进程启动时申请4g堆直接失败。还有一种是服务器物理内存快满了swap也不够Java进程在GC后申请新空间失败。排查思路先用free -hLinux或任务管理器确认机器可用内存再用jmap -heap pid查看JVM堆配置和当前使用情况。生产环境建议把-Xmx和容器limit设为匹配值比如容器limit 2gJVM就设-Xmx2g -Xms1g别让JVM有超出容器限制的幻想。5.3 逻辑BugHashMap中自定义key的经典陷阱这个坑我踩过两回必须单独拎出来说。当自定义对象作为HashMap的key时如果没有重写hashCode和equalsHashMap就退化成用内存地址判断相等性——每次new出来的对象即使内容完全一样也会被当成不同的key。举个例子MapPhoneNumber, String map new HashMap(); map.put(new PhoneNumber(010, 12345678), 张三); map.get(new PhoneNumber(010, 12345678)); // 返回null不重写hashCode和equals的话两次new的对象在HashMap看来是不同对象自然取不到值。而且更隐蔽的是如果你重写了equals但没重写hashCode已经放进Map里的key在查找时可能因为hashCode不一致而找不到——这又回到了我在1.3小结里强调的关系equals相等的对象必须保证hashCode相同。正确的重写姿势是用IDE自动生成或者用JDK 7的Objects工具类Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; PhoneNumber that (PhoneNumber) o; return areaCode.equals(that.areaCode) number.equals(that.number); } Override public int hashCode() { return Objects.hash(areaCode, number); }注意Objects.hash内部会创建数组性能上不如自己手写质数乘积累加但在业务代码里可读性更重要这点性能损耗可以忽略。5.4 API调用异常529、socket closed、timeout类问题热搜词里出现了“api error: 529 overloaded”、“cannot connect to api: the socket connection was closed unexpectedly”这类报错我虽然不展开讲具体的第三方API但从Java开发者的角度分享一下调用外部API时的排查方法论。这类问题绝大多数是网络层或服务端限流引起的不是Java代码本身的问题。529表示服务端过载是临时状态重试通常能解决socket closed通常是连接被服务端主动断开常见原因是超时设置过短或请求体过大timeout就是客户端设置的connectTimeout/readTimeout太小或者服务端真的慢了。我的处理习惯是三步先确认是偶发还是必现。偶发大概率是网络抖动或服务端限流增加重试机制指数退避抖动基本能解决。检查超时参数。HttpClient的connectTimeout设3秒readTimeout设10秒是很多项目的默认值。但如果目标API本身就慢比如AI推理接口readTimeout要调到30秒甚至更长。查看服务端返回的响应头或错误码。很多API会返回Retry-After头明确告诉客户端多久之后重试。如果对方开放了配额说明先看自己的调用频率是否超了。Java 11的java.net.http.HttpClient支持超时和重试但重试逻辑需要自己写。如果你用Spring的RestTemplate或WebClient也可以配置RetryTemplate工厂类设置重试次数和退避策略。我建议所有调用外部API的代码都做三件事设置明确的超时时间、记录入参和出参日志、对返回错误码做分类处理。这样即使出问题也能快速从日志定位是参数问题、网络问题还是服务端问题而不是让用户反馈了才知道。5.5 扩展思路这些API话题还能往深处挖聊到这里Java常用API的核心部分基本覆盖完了。但如果你在准备面试或者想把这块知识体系补齐还有几个方向值得继续深入并发APIThreadPoolExecutor的七个参数含义、CountDownLatch和CyclicBarrier的区别、ConcurrentHashMap的锁分段机制JDK 7和CASsynchronizedJDK 8。IO/NIOInputStream/OutputStream和Reader/Writer的对称关系FileChannel与零拷贝Files工具类的常用方法。反射与代理Class对象的获取方式、动态代理中JDK Proxy和CGLIB的差异以及为什么Spring默认用CGLIB。Optional与防御式编程怎么用Optional避免NullPointerException以及什么时候不该用Optional。新版本特性JDK 11的var、JDK 17的密封类、JDK 21的虚拟线程。这些内容每块都能单独写一篇长文。我的建议是不要贪多嚼不烂先把今天讲的String、集合、日期、Stream这四块吃透它们是Java日常开发的地基——我在排查那些隐性问题时十次里有八次最后都会落到这几个核心类上。