- Java63
- 数据库35
- 计算机基础30
- 技术文章精选集23
- 分布式18
- 系统设计12
- 框架10
- 走近作者9
- 知识星球9
- 高性能9
- 开源项目8
- 计算机书籍7
- 开发工具7
- 高可用6
- 走近项目5
- 代码质量4
- 面试准备3
- Java面试指北1
JDK 21 于 2023 年 9 月 19 日 发布,这是一个非常重要的版本,里程碑式。
JDK21 是 LTS(长期支持版),至此为止,目前有 JDK8、JDK11、JDK17 和 JDK21 这四个长期支持版了。
JDK 21 共有 15 个新特性,这篇文章会挑选其中较为重要的一些新特性进行详细介绍:
LinkedHashMap 简介
LinkedHashMap
是 Java 提供的一个集合类,它继承自 HashMap
,并在 HashMap
基础上维护一条双向链表,使得具备如下特性:
- 支持遍历时会按照插入顺序有序进行迭代。
- 支持按照元素访问顺序排序,适用于封装 LRU 缓存工具。
- 因为内部使用双向链表维护各个节点,所以遍历时的效率和元素个数成正比,相较于和容量成正比的 HashMap 来说,迭代效率会高很多。
DelayQueue 简介
DelayQueue
是 JUC 包(java.util.concurrent)
为我们提供的延迟队列,用于实现延时任务比如订单下单 15 分钟未支付直接取消。它是 BlockingQueue
的一种,底层是一个基于 PriorityQueue
实现的一个无界队列,是线程安全的。关于PriorityQueue
可以参考笔者编写的这篇文章:PriorityQueue 源码分析 。
PriorityQueue 源码分析 为我的知识星球(点击链接即可查看详细介绍以及加入方法)专属内容,已经整理到了《Java 必读源码系列》中。
在学习 NIO 之前,需要先了解一下计算机 I/O 模型的基础理论知识。还不了解的话,可以参考我写的这篇文章:Java IO 模型详解。
NIO 简介
在传统的 Java I/O 模型(BIO)中,I/O 操作是以阻塞的方式进行的。也就是说,当一个线程执行一个 I/O 操作时,它会被阻塞直到操作完成。这种阻塞模型在处理多个并发连接时可能会导致性能瓶颈,因为需要为每个连接创建一个线程,而线程的创建和切换都是有开销的。
阻塞队列简介
阻塞队列的历史
Java 阻塞队列的历史可以追溯到 JDK1.5 版本,当时 Java 平台增加了 java.util.concurrent
,即我们常说的 JUC 包,其中包含了各种并发流程控制工具、并发容器、原子类等。这其中自然也包含了我们这篇文章所讨论的阻塞队列。
为了解决高并发场景下多线程之间数据共享的问题,JDK1.5 版本中出现了 ArrayBlockingQueue
和 LinkedBlockingQueue
,它们是带有生产者-消费者模式实现的并发容器。其中,ArrayBlockingQueue
是有界队列,即添加的元素达到上限之后,再次添加就会被阻塞或者抛出异常。而 LinkedBlockingQueue
则由链表构成的队列,正是因为链表的特性,所以 LinkedBlockingQueue
在添加元素上并不会向 ArrayBlockingQueue
那样有着较多的约束,所以 LinkedBlockingQueue
设置队列是否有界是可选的(注意这里的无界并不是指可以添加任务数量的元素,而是说队列的大小默认为 Integer.MAX_VALUE
,近乎于无限大)。
CopyOnWriteArrayList 简介
在 JDK1.5 之前,如果想要使用并发安全的 List
只能选择 Vector
。而 Vector
是一种老旧的集合,已经被淘汰。Vector
对于增删改查等方法基本都加了 synchronized
,这种方式虽然能够保证同步,但这相当于对整个 Vector
加上了一把大锁,使得每个方法执行的时候都要去获得锁,导致性能非常低下。
JDK1.5 引入了 Java.util.concurrent
(JUC)包,其中提供了很多线程安全且并发性能良好的容器,其中唯一的线程安全 List
实现就是 CopyOnWriteArrayList
。关于java.util.concurrent
包下常见并发容器的总结,可以看我写的这篇文章:Java 常见并发容器总结 。

LinkedList 简介
LinkedList
是一个基于双向链表实现的集合类,经常被拿来和 ArrayList
做比较。关于 LinkedList
和ArrayList
的详细对比,我们 Java 集合常见面试题总结(上)有详细介绍到。
JVM 线上问题排查和性能调优也是面试常问的一个问题,尤其是社招中大厂的面试。
这篇文章,我会分享一些我看到的相关的案例。
下面是正文。
- 现象:线上某个服务有接口非常慢,通过监控链路查看发现,中间的 GAP 时间非常大,实际接口并没有消耗很多时间,并且在那段时间里有很多这样的请求。
- 分析:使用 JDK 自带的
jvisualvm
分析 dump 文件(MAT 也能分析)。 - 建议:对于 SQL 语句,如果监测到没有
where
条件的全表查询应该默认增加一个合适的limit
作为限制,防止这种问题拖垮整个系统 - 资料:实战案例:记一次 dump 文件分析历程转载 - HeapDump - 2022。