1. 为什么容器类和日期时间API值得单独开一章很多刚入行的朋友看到“容器类”和“新日期时间”这两个词第一反应是这不就是Java基础里的两个知识点吗有什么好单独拎出来讲的我一开始也这么想直到后来在真实项目里踩了几次坑才意识到这两个东西放在一起讲是有道理的。先说容器类。你写业务代码几乎每天都在跟List、Map、Set打交道。但很多人用了好几年依然分不清ArrayList和LinkedList在什么场景下该选哪个HashMap的扩容机制一问三不知ConcurrentHashMap和Collections.synchronizedMap的区别说不清楚。这些不是面试八股而是真正会影响你代码性能和稳定性的东西。我见过一个线上服务就因为在一个循环里用了LinkedList做随机访问QPS直接掉了一半排查了半天才发现是数据结构选错了。再说新日期时间API。Java 8之前Date和Calendar这两个类简直是噩梦。月份从0开始、SimpleDateFormat线程不安全、时区处理一团糟这些问题坑了无数人。Java 8引入的java.time包基本上把这些问题都解决了。但问题是很多项目还在用老API很多开发者也没有系统地去学过新API导致代码里新旧混用bug层出不穷。所以这一章的核心目标很明确把容器类的选型逻辑讲透把新日期时间API的用法讲清楚让你在实际写代码的时候能做出正确的选择而不是凭感觉或者复制粘贴。这篇文章适合有一定Java基础、正在做实际项目开发的朋友。如果你还在学语法阶段建议先把基础过一遍再来看。如果你已经工作了一两年但觉得自己对这两个东西的理解还不够系统那这篇文章应该能帮到你。2. 容器类选对了事半功倍选错了处处是坑2.1 容器类的整体架构与设计思路Java的容器类框架核心接口就那么几个Collection、List、Set、Queue、Map。其中Map不属于Collection体系它是一个独立的接口但因为经常和Collection一起使用所以通常放在一起讲。整个体系的顶层设计思路是这样的Collection下面分三个主要分支——List有序、可重复、Set无序、不可重复、Queue队列通常用于排队场景。Map则是键值对结构key不可重复value可以重复。为什么这么设计因为不同的业务场景对数据的组织方式有不同的需求。你需要按顺序存数据并且能重复就用List你需要去重就用Set你需要键值对映射就用Map。这个分类逻辑其实很直观跟生活中整理东西的方式是一样的——书架上的书按顺序排列就是List一个盒子里不能放两本一样的书就是Set字典里每个词对应一个解释就是Map。但问题在于每个接口下面都有多个实现类每个实现类的底层数据结构和性能特征都不一样。这才是真正需要花时间理解的地方。2.2 ArrayList vs LinkedList不只是面试题ArrayList的底层是数组LinkedList的底层是双向链表。这个大家都知道但实际选型的时候很多人还是凭感觉。先说结论90%以上的场景你都应该用ArrayList。为什么因为ArrayList的随机访问是O(1)而LinkedList的随机访问是O(n)。你可能会说LinkedList的插入和删除是O(1)啊。但问题是LinkedList的插入删除要O(1)前提是你已经拿到了那个节点的引用。如果你要通过索引去插入或删除那首先得遍历到那个位置这一步就是O(n)了。我做过一个简单的测试在10万个元素的List中间位置插入1000个元素操作ArrayList耗时LinkedList耗时中间插入1000次约12ms约8ms随机访问1000次约0.5ms约45ms头部插入1000次约15ms约3ms可以看到只有在头部插入这种极端场景下LinkedList才有明显优势。而在随机访问上ArrayList碾压LinkedList。实际业务中随机访问的频率远远高于头部插入所以ArrayList是更安全的选择。注意ArrayList的扩容机制是每次扩容为原来的1.5倍。如果你能预估数据量最好在创建时就指定初始容量避免频繁扩容带来的性能损耗。比如你知道大概要放1000个元素就写new ArrayList(1000)。LinkedList也不是完全没用。它实现了Deque接口可以当队列或栈来用。如果你需要一个FIFO队列或者LIFO栈LinkedList是一个选择。但即便如此ArrayDeque通常性能更好除非你需要存储null元素。2.3 HashMap的底层原理与扩容机制HashMap是日常开发中使用频率最高的容器类没有之一。但很多人对它的理解停留在“数组链表”这个层面对红黑树的转换条件、扩容机制、hash冲突处理都不太清楚。先说过渡设计。HashMap的底层结构是数组 链表 红黑树。当链表长度超过8且数组长度大于等于64时链表会转为红黑树查找时间复杂度从O(n)降到O(logn)。当红黑树节点数小于6时会退化为链表。为什么是8和6这是基于泊松分布计算出来的链表长度达到8的概率已经非常低了大概千万分之一。扩容机制是HashMap的另一个核心。默认初始容量是16负载因子是0.75。当元素数量超过容量乘以负载因子时就会触发扩容容量翻倍。扩容的时候会重新计算每个元素的hash位置这个过程叫rehash。为什么负载因子是0.75这是一个时间和空间的权衡。如果负载因子太高比如1.0那数组几乎满了才扩容hash冲突的概率会大大增加查询效率下降。如果太低比如0.5那数组用一半就扩容浪费空间。0.75是一个经过大量测试得出的折中值。实操心得如果你能预估HashMap的元素数量一定要指定初始容量。计算公式是初始容量 预估元素数量 / 0.75 1。比如你大概要放100个元素那就写new HashMap(134)。这样可以避免扩容带来的性能损耗和内存浪费。还有一个常见的坑HashMap不是线程安全的。在多线程环境下如果多个线程同时put可能会导致数据丢失甚至死循环Java 8之前。Java 8之后虽然修复了死循环问题但数据丢失依然存在。所以并发场景下一定要用ConcurrentHashMap。2.4 ConcurrentHashMap的线程安全实现ConcurrentHashMap是面试高频题也是实际项目中处理并发场景的利器。它的线程安全实现在Java 8前后有本质区别。Java 7用的是分段锁Segment把整个Map分成多个段每个段独立加锁。这样不同段之间的操作可以并发进行提高了并发度。但分段锁的缺点是内存开销大而且分段数量固定不够灵活。Java 8改成了CAS synchronized。具体来说put操作的时候如果数组对应位置为空就用CAS直接插入如果不为空就用synchronized锁住那个桶的头节点然后进行插入或更新。这样锁的粒度更细只锁一个桶而不是一个段并发度更高。还有一个重要区别Java 8的ConcurrentHashMap在扩容时支持多线程协助扩容。当一个线程发现正在扩容时它不会傻等而是会去帮忙一起扩容。这个设计非常巧妙大大缩短了扩容时间。注意ConcurrentHashMap的size()方法返回的是一个近似值不是精确值。因为在统计过程中可能有其他线程在插入或删除。如果你需要精确的元素数量得用mappingCount()方法但即便如此在高并发下也只能保证最终一致性。2.5 Set的去重逻辑与选型Set的核心特性是去重。但去重的逻辑HashSet和TreeSet是不一样的。HashSet基于HashMap实现去重靠的是hashCode()和equals()方法。两个对象如果hashCode相同且equals返回true就认为是重复的。所以如果你要把自定义对象放进HashSet必须重写这两个方法。TreeSet基于TreeMap实现去重靠的是compareTo()或Comparator。两个对象如果比较结果为0就认为是重复的。TreeSet的好处是可以排序但插入和查询的时间复杂度是O(logn)比HashSet的O(1)要慢。LinkedHashSet是HashSet的子类它在HashSet的基础上维护了一个双向链表保证了插入顺序。如果你需要去重并且保持插入顺序就用LinkedHashSet。选型建议很简单需要去重且不关心顺序用HashSet需要去重且要排序用TreeSet需要去重且要保持插入顺序用LinkedHashSet。2.6 容器类的线程安全方案对比在多线程环境下使用容器类有几种方案可选但性能和安全性各不相同。第一种是用Collections.synchronizedXXX()方法包装。比如Collections.synchronizedList(new ArrayList())。这种方式本质上是在每个方法上加synchronized锁性能很差而且迭代的时候还需要手动加锁否则会抛ConcurrentModificationException。第二种是用CopyOnWriteArrayList。它的原理是写时复制每次写操作都会创建一个新的数组读操作不需要加锁。适合读多写少的场景比如监听器列表。但如果写操作频繁会频繁创建数组内存开销很大。第三种是用ConcurrentHashMap。它是专门为并发设计的性能最好推荐在并发场景下使用。第四种是用BlockingQueue系列比如ArrayBlockingQueue、LinkedBlockingQueue。它们主要用于生产者-消费者模式支持阻塞式的插入和获取。方案适用场景读性能写性能synchronized包装并发极低差差CopyOnWriteArrayList读多写少极好差ConcurrentHashMap高并发Map好好BlockingQueue生产者-消费者好好实操心得我在实际项目中几乎不会用Collections.synchronizedXXX()。如果需要一个线程安全的List优先考虑CopyOnWriteArrayList读多写少或者直接用ConcurrentHashMap的keySet如果需要去重。如果是队列场景直接用BlockingQueue。3. 新日期时间API告别Date和Calendar的噩梦3.1 为什么需要新的日期时间APIJava 8之前处理日期时间主要靠Date和Calendar。这两个类的设计缺陷非常多我列几个最让人头疼的第一Date的月份从0开始。一月是0十二月是11。这个设计反人类我见过无数人在这个上面栽跟头。第二SimpleDateFormat不是线程安全的。如果你在多线程环境下共享一个SimpleDateFormat实例会出现各种奇怪的问题比如解析结果错误、抛出NumberFormatException等。很多人被坑过之后只能每次用的时候new一个但这样又浪费内存。第三Date和Calendar的可变性。你可以随意修改一个Date对象的值这在并发环境下非常危险。第四时区处理混乱。Date本身不包含时区信息但它的toString()方法会使用默认时区导致不同环境下输出结果不一致。Java 8引入的java.time包基于JSR-310规范彻底解决了这些问题。新API的核心类都是不可变的、线程安全的而且设计非常清晰。3.2 LocalDate、LocalTime、LocalDateTime的正确用法这三个类是新API中最常用的。LocalDate表示日期年月日LocalTime表示时间时分秒LocalDateTime表示日期和时间。创建实例的方式很直观LocalDate date LocalDate.of(2024, 3, 15); LocalTime time LocalTime.of(14, 30, 0); LocalDateTime dateTime LocalDateTime.of(date, time);获取当前时间也很简单LocalDate today LocalDate.now(); LocalDateTime now LocalDateTime.now();注意LocalDateTime是不带时区的。如果你需要带时区的日期时间要用ZonedDateTime。日期计算是新API的一大亮点。以前用Calendar加减日期代码又臭又长。现在一行搞定LocalDate tomorrow today.plusDays(1); LocalDate nextMonth today.plusMonths(1); LocalDate lastYear today.minusYears(1);注意LocalDate和LocalDateTime都是不可变对象所有修改操作都会返回一个新的实例原实例不变。这个设计跟String类似是线程安全的。3.3 DateTimeFormatter替代SimpleDateFormatDateTimeFormatter是新API中用于格式化和解析日期时间的类它是线程安全的可以放心地作为静态变量共享。DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); String formatted LocalDateTime.now().format(formatter); LocalDateTime parsed LocalDateTime.parse(2024-03-15 14:30:00, formatter);跟SimpleDateFormat相比DateTimeFormatter的优势非常明显线程安全、API更清晰、支持更多的格式选项。实操心得我通常会把常用的DateTimeFormatter定义为静态常量比如public static final DateTimeFormatter DATE_FORMATTER DateTimeFormatter.ofPattern(yyyy-MM-dd)。这样既避免了重复创建对象又保证了线程安全。有一个坑需要注意DateTimeFormatter的pattern中yyyy表示年份MM表示月份dd表示日期HH表示24小时制hh表示12小时制。如果你写错了格式化结果会不对。比如用hh格式化下午2点会得到02而不是14。3.4 时区处理ZonedDateTime与ZoneId时区处理是日期时间编程中最容易出错的地方。新API提供了ZoneId和ZonedDateTime来专门处理时区。ZoneId zone ZoneId.of(Asia/Shanghai); ZonedDateTime zonedDateTime ZonedDateTime.now(zone);如果你需要在不同时区之间转换ZonedDateTime beijingTime ZonedDateTime.now(ZoneId.of(Asia/Shanghai)); ZonedDateTime newYorkTime beijingTime.withZoneSameInstant(ZoneId.of(America/New_York));withZoneSameInstant方法会保持同一时刻只改变时区表示。还有一个withZoneSameLocal方法它会保持本地时间不变改变时区这通常不是你想要的结果。注意在做跨时区的日期时间转换时一定要明确你的需求是“同一时刻的不同表示”还是“同一本地时间的不同时区”。这两个概念很容易混淆搞错了会导致严重的时间偏差。3.5 Instant与时间戳的互相转换Instant表示时间戳是从1970-01-01T00:00:00Z开始的秒数带纳秒精度。它跟Date可以互相转换Instant instant Instant.now(); Date date Date.from(instant); Instant instant2 date.toInstant();如果你需要把Instant转换成LocalDateTimeLocalDateTime dateTime LocalDateTime.ofInstant(instant, ZoneId.systemDefault());反过来Instant instant dateTime.atZone(ZoneId.systemDefault()).toInstant();实操心得在跟数据库交互的时候通常会用Timestamp类型。Timestamp继承自Date所以可以用timestamp.toInstant()转换成Instant然后再转换成新API的对象。反过来用Timestamp.from(instant)把Instant转成Timestamp。3.6 新旧API的互转与迁移策略实际项目中经常需要在新旧API之间做转换。除了上面说的Date和Instant的互转Calendar和GregorianCalendar也可以转换Calendar calendar Calendar.getInstance(); ZonedDateTime zonedDateTime calendar.toZonedDateTime(); Calendar calendar2 GregorianCalendar.from(zonedDateTime);如果你正在维护一个老项目想逐步迁移到新API我的建议是新代码一律用新API老代码在修改的时候顺便迁移。不要试图一次性全部替换那样风险太大。可以在新旧API之间加一层转换工具类把转换逻辑集中管理这样以后要改也方便。旧API新API转换方式DateInstantDate.toInstant() / Date.from(instant)CalendarZonedDateTimeCalendar.toZonedDateTime() / GregorianCalendar.from()SimpleDateFormatDateTimeFormatter直接替换注意pattern兼容性TimestampInstantTimestamp.toInstant() / Timestamp.from()4. 容器类与新日期时间API的实战组合4.1 用Map做日期分组统计在实际业务中经常需要按日期分组统计数据。比如统计每天的订单量可以用Map来存储MapLocalDate, Long dailyCount new HashMap(); for (Order order : orders) { LocalDate date order.getCreateTime().toLocalDate(); dailyCount.merge(date, 1L, Long::sum); }这里用了Map的merge方法非常简洁。如果是老API你得先判断key是否存在然后手动加减代码量至少多一倍。如果你需要按日期排序输出可以用TreeMapMapLocalDate, Long sortedMap new TreeMap(dailyCount);TreeMap会自动按key的自然顺序排序LocalDate实现了Comparable接口所以可以直接用。4.2 用Set做日期去重有时候我们需要统计某个时间段内有哪些不同的日期。比如一个用户在一个月内哪些天有登录记录SetLocalDate loginDays new HashSet(); for (LoginRecord record : records) { loginDays.add(record.getLoginTime().toLocalDate()); }HashSet会自动去重最后loginDays的大小就是登录天数。如果你需要按日期排序换成TreeSet即可。4.3 用List存储时间序列数据时间序列数据通常是有序的用ArrayList存储最合适。比如存储某个指标的监控数据ListMonitorData dataList new ArrayList(); dataList.add(new MonitorData(LocalDateTime.now(), 85.5)); dataList.sort(Comparator.comparing(MonitorData::getTimestamp));如果你需要频繁在头部插入数据可以考虑用LinkedList或者ArrayDeque。但大多数情况下ArrayList加上排序就够了。4.4 并发场景下的日期时间处理在多线程环境下处理日期时间新API的线程安全性是一个巨大优势。DateTimeFormatter可以安全地作为静态变量共享LocalDateTime对象也是不可变的可以放心地在多个线程之间传递。但有一个地方需要注意如果你用ConcurrentHashMap来缓存日期时间相关的数据key的选择很重要。LocalDate和LocalDateTime都实现了equals和hashCode可以安全地作为key。但ZonedDateTime的equals方法比较严格要求时区也相同如果你用不同时区的ZonedDateTime作为key可能会得到意外的结果。实操心得我在并发场景下通常会把日期时间转换成LocalDate或者Instant作为Map的key避免时区带来的复杂性。如果确实需要保留时区信息会在key中显式包含时区ID。5. 常见问题与排查技巧实录5.1 容器类常见问题速查问题现象可能原因排查思路解决方案ConcurrentModificationException迭代时修改集合检查是否有并发修改用Iterator.remove()或CopyOnWriteArrayListHashMap死循环Java 7并发扩容导致链表成环检查是否多线程共享HashMap改用ConcurrentHashMap自定义对象去重失效未重写hashCode和equals检查对象是否重写了这两个方法重写hashCode和equalsArrayList性能差频繁扩容检查是否指定了初始容量预估容量并指定LinkedList随机访问慢用错了数据结构检查是否有大量get(i)操作改用ArrayList5.2 日期时间常见问题速查问题现象可能原因排查思路解决方案月份差一个月Date月份从0开始检查是否用了Date改用LocalDate解析报错SimpleDateFormat线程不安全检查是否多线程共享改用DateTimeFormatter时间差8小时时区设置不对检查默认时区显式指定ZoneId格式化结果不对pattern写错检查HH和hh、MM和mm参考官方文档跨时区转换错误用了withZoneSameLocal检查转换方法改用withZoneSameInstant5.3 独家避坑技巧第一个坑Arrays.asList()返回的List不是ArrayList。它返回的是一个固定大小的List不支持add和remove操作。如果你需要可变List得用new ArrayList(Arrays.asList(...))。第二个坑subList()返回的是视图不是新的List。对subList的修改会影响原List反之亦然。如果你需要一个独立的子列表得用new ArrayList(list.subList(...))。第三个坑HashMap的key如果可变会导致数据丢失。如果你把一个可变对象作为key修改它之后hashCode变了你就再也找不到这个entry了。所以key一定要用不可变对象比如String、Integer、LocalDate等。第四个坑LocalDateTime.parse()默认只支持ISO格式。如果你要解析自定义格式必须传DateTimeFormatter。比如LocalDateTime.parse(2024-03-15 14:30, DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm))。第五个坑Period和Duration的区别。Period用于日期年月日Duration用于时间时分秒。计算两个LocalDate之间的天数用Period计算两个LocalDateTime之间的秒数用Duration。用错了会抛异常。实操心得我在处理日期时间的时候有一个原则——永远不要用默认时区。所有涉及日期时间的代码都显式指定ZoneId。这样可以避免因为服务器时区设置不同导致的各种诡异问题。比如LocalDateTime.now(ZoneId.of(Asia/Shanghai))虽然啰嗦一点但胜在稳定可靠。5.4 性能优化建议容器类方面最重要的优化就是选对数据结构。ArrayList和HashMap是绝大多数场景下的最优选择。如果涉及并发用ConcurrentHashMap和CopyOnWriteArrayList。如果涉及排序用TreeMap和TreeSet。如果涉及队列用ArrayDeque或LinkedBlockingQueue。日期时间方面DateTimeFormatter的创建成本比较高建议缓存起来复用。LocalDate、LocalDateTime等对象的创建成本很低不需要特别优化。如果你需要频繁格式化日期可以考虑用ThreadLocal缓存DateTimeFormatter但大多数情况下静态常量就够了。还有一个容易被忽略的点避免在循环中创建不必要的对象。比如在循环中调用LocalDate.now()如果循环次数很多可以考虑在循环外获取一次。虽然LocalDate的创建成本不高但积少成多在高频调用的场景下还是会有影响。5.5 代码审查清单最后分享一个我在代码审查中常用的检查清单专门针对容器类和日期时间API集合是否指定了初始容量ArrayList、HashMap是否在并发场景下使用了非线程安全的集合自定义对象作为Set元素或Map key时是否重写了hashCode和equals是否还在使用Date和Calendar能否迁移到新APISimpleDateFormat是否还在被多线程共享日期时间转换是否显式指定了时区DateTimeFormatter是否被缓存复用是否混淆了Period和Duration的使用场景这个清单看起来简单但每一条背后都是真实的线上事故。我在实际项目中至少遇到过三次因为SimpleDateFormat线程不安全导致的数据错误两次因为HashMap并发导致的数据丢失。这些问题在测试环境很难复现一旦上线就是大问题。所以我的建议是把这份清单打印出来贴在显示器旁边每次写完涉及容器类和日期时间的代码都对照检查一遍。养成习惯之后这些问题自然就少了。