编程范式与 Java 演进
一、编程范式基础
1.1 词源与本义
Paradigm 源自希腊语 paradeigma(παράδειγμα),意为"模式、范例、典型"。
科学哲学中,托马斯·库恩(Thomas Kuhn)在《科学革命的结构》里用"范式"指:
一个科学共同体在特定时期共同接受的理论框架、方法论和问题求解模式。范式转换意味着整个认知体系的更替。
移植到编程领域:
编程范式就是程序员看待程序结构与执行逻辑的"世界观"——它决定了你如何组织代码、如何抽象问题、如何理解"计算"本身。
1.2 核心定义
编程范式是一种构建程序结构和组织计算逻辑的典型风格与方法论体系,它规定了:
- 程序的基本组成单元是什么(函数?对象?过程?规则?)
- 计算如何被描述和执行(顺序执行?消息传递?约束求解?)
- 状态如何管理(可变 vs 不可变,共享 vs 隔离)
- 代码如何组织和复用
关键区分:范式 ≠ 语言。一门语言可以支持多种范式(如 Python 同时支持命令式、面向对象、函数式);一种范式也可以被多种语言实现。范式是思维方式,语言是承载工具。
1.3 主要范式全景
编程范式
├── 命令式(Imperative)
│ ├── 过程式(Procedural)—— C、Pascal
│ └── 结构化编程(Structured)—— 顺序/选择/循环
│
├── 面向对象(Object-Oriented)
│ ├── 基于类(Class-based)—— Java、C++、C#
│ └── 基于原型(Prototype-based)—— JavaScript
│
├── 声明式(Declarative)
│ ├── 函数式(Functional)—— Haskell、Clojure、Scala
│ ├── 逻辑式(Logic)—— Prolog
│ ├── 数据流(Dataflow)
│ └── 响应式(Reactive)—— Rx 系列
│
└── 其他
├── 泛型编程(Generic)—— C++ STL、Java Generics
├── 元编程(Metaprogramming)—— Lisp 宏、Ruby
├── 事件驱动(Event-driven)—— GUI、Node.js
├── 并发范式(Concurrent)—— Actor、CSP
└── 约束编程(Constraint)—— 调度、规划
1.4 容易混淆的概念辨析
范式 vs 设计模式
- 范式是宏观的编程世界观(如"面向对象")
- 设计模式是特定范式下解决具体问题的套路(如"单例模式"是 OOP 下的一种设计模式)
范式 vs 架构风格
- 范式关注代码组织和计算模型(微观)
- 架构风格关注系统组件的拓扑结构和交互方式(宏观,如微服务、分层架构)
二、命令式编程详解
2.1 词源
Imperative 来自拉丁语 imperare(in- + parare "准备、命令"),意为"命令的、指令的"。
在语法学中,imperative mood 就是祈使语气——直接下达命令。
2.2 核心世界观
计算是一系列状态变更的操作序列。程序就是给计算机的一串指令,计算机按顺序执行,每一步都改变某个状态。
2.3 思维模型
你是一个指挥官,告诉计算机"先做A,再做B,然后如果C成立就做D"。
你关心的是过程——如何一步步到达目标。
2.4 核心特征
| 特征 | 说明 |
|---|---|
| 状态可变 | 变量就是"变化的量",赋值是核心操作 |
| 顺序执行 | 代码按书写顺序从上到下执行 |
| 循环驱动 | 用 for/while 重复执行代码块 |
| 副作用普遍 | 修改状态、IO 操作都是副作用,且默认存在 |
| 关注 How | 详细描述每一步怎么做 |
2.5 举例:求列表元素之和
// 命令式:一步步改变累加器的状态
int sum = 0; // 初始化状态
for (int i = 0; i < list.size(); i++) {
sum = sum + list.get(i); // 每轮更新状态
}
return sum;
解读:我们明确告诉计算机——初始化 sum 为 0,然后从第 0 个元素开始遍历,每次把元素值加到 sum 上,直到遍历完所有元素。每一步都在改变 sum 的状态。
三、函数式编程详解
3.1 词源
Functional 来自拉丁语 functio(执行、履行)。
在数学中,function(函数) 是从输入到输出的确定映射——给定相同输入,永远产生相同输出。
3.2 核心世界观
计算是数学函数的求值。程序由函数组合而成,函数是一等公民,数据不可变,避免副作用。
3.3 思维模型
你是一个数学家,定义输入和输出之间的映射关系。
你关心的是结果——什么是正确的答案,而不是怎么一步步算出来。
3.4 核心特征
| 特征 | 说明 |
|---|---|
| 数据不可变 | 数据一旦创建就不能修改,"修改"意味着创建新值 |
| 纯函数 | 相同输入永远产生相同输出,没有副作用 |
| 函数是一等公民 | 函数可以作为参数、返回值、存入数据结构 |
| 递归代替循环 | 用函数自身调用代替迭代循环 |
| 关注 What | 描述目标是什么,执行细节交给运行时 |
3.5 核心概念
纯函数(Pure Function)
满足两个条件:
- 确定性:相同输入永远返回相同输出
- 无副作用:不修改任何外部状态(不修改变量、不写文件、不发网络请求)
-- 纯函数:输入决定输出,无副作用
add :: Int -> Int -> Int
add x y = x + y
高阶函数(Higher-Order Function)
可以接受函数作为参数,或返回函数的函数。
-- map 是高阶函数:接受一个函数和一个列表
map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs
不可变数据(Immutable Data)
数据一旦创建就不能改变。"修改"操作会返回一个新的数据结构,原数据保持不变。
函数组合(Function Composition)
用 . 把多个函数组合成一个新函数。
-- 先加1,再乘2
add1ThenDouble = (*2) . (+1)
3.6 举例:求列表元素之和
-- 函数式:描述"求和"是什么,而不是怎么算
sum list = foldl (+) 0 list
解读:我们说"求和就是用加法把列表折叠起来,初始值是 0"。foldl 是一个通用的递归抽象,它知道怎么遍历列表,我们只需要提供运算和初始值。
四、函数式 vs 命令式:深度对比
4.1 状态管理对比
| 维度 | 命令式 | 函数式 |
|---|---|---|
| 状态 | 可变(mutable),变量就是"变化的量" | 不可变(immutable),"变量"更像数学里的常量绑定 |
| 赋值 | 核心操作,反复覆盖旧值 | 避免重新赋值,每次产生新值 |
| 共享状态 | 普遍存在,需要锁/同步来保护 | 天然避免,数据不可变所以不存在并发安全问题 |
举例:对列表每个元素乘2
// 命令式:一步步改变列表状态
List<Integer> result = new ArrayList<>();
for (int i = 0; i < list.size(); i++) {
result.add(list.get(i) * 2); // 每次都在改变 result 的状态
}
-- 函数式:描述映射关系,不改变任何东西
map (*2) list -- 产生一个新列表,原列表不变
4.2 控制流对比
| 维度 | 命令式 | 函数式 |
|---|---|---|
| 基本结构 | 顺序、分支、循环(for/while) | 函数调用、递归、高阶函数 |
| 循环方式 | 迭代(iteration),用循环变量驱动 | 递归(recursion),用函数自身调用驱动 |
| 跳转 | goto / break / continue / return | 函数返回值,没有"跳出"概念 |
举例:求阶乘
// 命令式:用循环改变累加器
int factorial(int n) {
int result = 1; // 初始化状态
for (int i = 2; i <= n; i++) {
result = result * i; // 每轮更新状态
}
return result;
}
-- 函数式:用递归定义
factorial 0 = 1
factorial n = n * factorial (n - 1)
-- 或用 fold(折叠)抽象递归模式
factorial n = foldl (*) 1 [1..n]
4.3 函数地位对比
| 维度 | 命令式 | 函数式 |
|---|---|---|
| 函数本质 | 过程(procedure),一段可复用的指令序列 | 一等公民(first-class citizen),可以作为参数、返回值、存入数据结构 |
| 副作用 | 默认存在且常见(修改变量、IO、修改参数) | 尽量避免,纯函数只有输入输出 |
| 组合方式 | 顺序调用 + 共享变量 | 函数组合(function composition) |
4.4 表达力对比
| 维度 | 命令式 | 函数式 |
|---|---|---|
| 关注点 | How(怎么做)—— 详细的步骤 | What(是什么)—— 目标和结果 |
| 抽象粒度 | 较低,需要管理细节 | 较高,可以用高阶函数抽象通用模式 |
| 代码复用 | 通过继承/组合/模板 | 通过高阶函数、组合子(combinator) |
举例:从列表中筛选偶数并平方
// 命令式:手动管理循环、条件、累加
List<Integer> result = new ArrayList<>();
for (int num : list) {
if (num % 2 == 0) {
result.add(num * num);
}
}
// 函数式(Java Stream):描述数据变换管道
list.stream()
.filter(n -> n % 2 == 0)
.map(n -> n * n)
.collect(Collectors.toList());
注意函数式版本的声明性:你说的是"筛选+映射+收集"这些做什么,而不是"初始化列表→遍历→判断→添加"这些怎么做。
4.5 并发与性能对比
| 维度 | 命令式 | 函数式 |
|---|---|---|
| 并发安全 | 需要手动加锁/同步,容易死锁、竞态 | 不可变数据天然线程安全,不需要锁 |
| 并行化 | 困难,需要考虑共享状态 | 容易,纯函数可以任意并行执行 |
| 内存效率 | 原地修改,内存效率高 | 不可变性导致频繁创建新对象,依赖GC和结构共享 |
| 运行速度 | 通常更快,直接操作硬件模型 | 可能有额外开销(闭包、递归、惰性求值) |
4.6 核心概念对照表
| 命令式概念 | 函数式对应概念 | 说明 |
|---|---|---|
| 变量赋值 | 值绑定(binding) | 绑定不可变,变量只是值的名字 |
| 循环 | 递归 / fold / map | 用递归或高阶函数替代循环 |
| 语句(statement) | 表达式(expression) | 一切都是表达式,都有返回值 |
| 副作用(side effect) | 纯函数(pure function) | 纯函数只依赖输入,不改变外部世界 |
| 命令序列 | 函数组合 | 用组合子连接函数 |
| 可变数据结构 | 持久化数据结构 | 修改时返回新版本,旧版本不变 |
| for/while | map / filter / reduce | 高阶函数抽象常见递归模式 |
| null | Maybe / Optional | 用类型系统表达"可能不存在" |
4.7 一句话总结
命令式编程是"告诉计算机每一步怎么做"——像写菜谱,步骤详尽;
函数式编程是"告诉计算机结果应该是什么"——像写数学公式,定义关系。
五、Java 的范式定位
5.1 结论
多范式语言,以面向对象为主,逐步融入函数式特性。
5.2 历史演进线
| 版本 | 年份 | 范式特征 |
|---|---|---|
| Java 1.0 ~ 1.4 | 1996~2002 | 纯粹的面向对象命令式语言 |
| Java 5 | 2004 | 引入泛型(泛型编程要素) |
| Java 8 | 2014 | 范式转折点:Lambda + Stream + Optional + 函数式接口 |
| Java 9+ | 2017~ | 持续强化函数式、数据导向、声明式能力 |
5.3 精确判定
Java 不是纯函数式语言,也不是纯命令式语言,而是:
以面向对象为主体、命令式为基础、函数式为增强的多范式语言
5.4 各范式在 Java 中的体现
| 范式 | Java 中的体现 | 程度 |
|---|---|---|
| 面向对象(OOP) | 类、对象、继承、接口、多态、封装 | 主体范式,语言的骨架 |
| 命令式 | 变量赋值、for/while 循环、if/else、副作用 | 基础范式,最底层的执行模型 |
| 函数式 | Lambda、Stream、函数式接口、Optional、方法引用 | 增强范式,自 Java 8 起逐步加入 |
| 泛型编程 | 泛型类、泛型方法、通配符 | 支持,但受类型擦除限制 |
| 并发范式 | Thread、Executor、CompletableFuture、虚拟线程 | 丰富的并发支持 |
| 元编程 | 反射、注解处理器、字节码增强 | 有限支持,不是语言核心特性 |
5.5 为什么说 Java 不是"函数式语言"
虽然 Java 8+ 加入了大量函数式特性,但它本质上不是函数式语言,原因有三:
-
状态可变性是默认的:Java 的变量默认可变,不可变(final)反而需要显式声明。纯函数式语言则相反——默认不可变。
-
副作用无处不在:Java 的方法默认可以有副作用(修改字段、修改参数对象、IO 操作),没有类型系统层面的约束。Haskell 用 IO Monad 把副作用隔离在类型系统里。
-
OOP 仍是第一公民:Java 的一切都包裹在类里,函数不是真正的一等公民——Lambda 本质上是函数式接口的语法糖,最终还是对象。
打个比方:Java 8 就像一个传统的中餐厨师学会了做寿司——他能做,但厨房的核心设备(灶台、炒锅)还是为中餐设计的。
5.6 实际使用中的范式选择
| 场景 | 推荐范式 | 原因 |
|---|---|---|
| 传统业务逻辑 | OOP + 命令式 | 最自然、最符合 Java 设计初衷 |
| 集合数据处理 | Stream(函数式风格) | 简洁、声明式、易读 |
| 并发异步 | CompletableFuture / 虚拟线程 | 函数式组合 + 异步 |
| 简单工具方法 | 纯函数风格 | 无副作用、易测试 |
六、Java LTS 版本演进轨迹
6.1 总体趋势
Java 9 到 21 的迭代,表面是语法糖和 API 扩充,底层是一场静悄悄的范式迁移:Java 在不打破向后兼容的前提下,持续向函数式 + 声明式 + 数据导向的方向演进。
核心逻辑:
让 Java 程序员能用更少的代码表达更多的意图,把"怎么做"的细节越来越多地交给编译器和运行时。
6.2 Java 9(2017)—— 基础设施铺垫
核心特性
| 特性 | 说明 | 范式意义 |
|---|---|---|
| JPMS 模块系统 | Project Jigsaw,把 JDK 本身模块化 | 架构层面的封装增强 |
| JShell | 交互式 REPL 工具 | 降低函数式探索门槛 |
| 接口私有方法 | 接口中可以有 private 方法 | 接口越来越像"带有实现的契约" |
| Stream API 增强 | takeWhile / dropWhile / ofNullable | 函数式能力补强 |
| Optional 增强 | stream() / ifPresentOrElse() / or() | 函数式错误处理完善 |
| 集合工厂方法 | List.of() / Set.of() / Map.of() | 不可变集合便捷创建,向"默认不可变"靠拢 |
范式定位
Java 9 是基础设施年——模块系统是工程层面的,JShell 和集合工厂方法是函数式体验的铺垫。真正的范式跃迁还没开始。
6.3 Java 11(2018)—— 平稳过渡
核心特性
| 特性 | 说明 | 范式意义 |
|---|---|---|
| var 局部变量类型推断 | var list = new ArrayList<String>(); | 减少样板代码,向"声明式"靠拢 |
| Lambda 中使用 var | (var x, var y) -> x + y | 类型推断延伸到函数式场景 |
| HTTP Client 标准化 | 从孵化器转正,支持异步/响应式 | 异步编程的官方支持 |
| String API 增强 | isBlank() / strip() / lines() / repeat() | 小修小补 |
| ZGC 实验 | 低延迟垃圾回收器 | 为函数式风格的内存压力做底层支撑 |
范式定位
Java 11 是过渡版本——var 是重要的语法简化,但范式层面的大动作还在后面。它更像是 Java 8 函数式革命后的"消化期"。
6.4 Java 17(2021)—— 范式跃迁的真正起点
Java 17 是继 Java 8 之后最重要的 LTS 版本,它引入的三个特性——Record、Sealed Class、Pattern Matching——共同指向一个方向:数据导向编程(Data-Oriented Programming)。
Record 类(记录类)
字面意思:record = 记录、记载。它就是一个纯数据载体——只存数据,没有行为(或只有极少行为)。
// 以前:写一个不可变数据类要几十行
public final class Point {
private final int x;
private final int y;
public Point(int x, int y) { this.x = x; this.y = y; }
public int x() { return x; }
public int y() { return y; }
@Override public boolean equals(Object o) { ... }
@Override public int hashCode() { ... }
@Override public String toString() { ... }
}
// 现在:一行搞定
public record Point(int x, int y) {}
范式意义:
- Java 第一次在语言层面支持**代数数据类型(ADT)**中的"积类型"(product type)
- 默认不可变、自动生成 equals/hashCode/toString——函数式语言的核心数据结构特性
- 标志着 Java 从"一切皆对象(有行为)"向"数据与行为分离"倾斜
- 类比:Haskell 的
data、Scala 的case class、Kotlin 的data class
Sealed Class(密封类)
字面意思:sealed = 密封的、封闭的。密封类精确控制谁能继承它——不是开放给所有人,也不是完全禁止继承,而是"白名单制"。
public sealed interface Shape permits Circle, Rectangle, Triangle {
// 只有 Circle、Rectangle、Triangle 可以实现 Shape
}
public final class Circle implements Shape { ... }
public final class Rectangle implements Shape { ... }
public final class Triangle implements Shape { ... }
范式意义:
- 这是代数数据类型中的"和类型"(sum type)——一个类型可以是若干种情况之一
- 与 Record 配合,就能表达完整的 ADT:
Shape要么是Circle,要么是Rectangle,要么是Triangle - 这是函数式语言的标配(Haskell 的
data、Scala 的sealed trait) - 为模式匹配提供了穷举检查的基础——编译器能验证你是否覆盖了所有情况
Pattern Matching for switch(预览)
字面意思:模式匹配——不是简单的值比较,而是匹配数据的结构和类型。
// 以前:instanceof + 强转 + 提取
if (obj instanceof String) {
String s = (String) obj;
System.out.println(s.length());
}
// Java 16+:模式匹配的 instanceof
if (obj instanceof String s) {
System.out.println(s.length()); // 直接用 s,不用强转
}
// Java 17 预览:switch 模式匹配
String format(Object o) {
return switch (o) {
case Integer i -> "int: " + i;
case String s -> "string: " + s;
case Double d -> "double: " + d;
default -> "unknown";
};
}
范式意义:
- 这是函数式语言的标志性特性——根据数据的结构来分支处理,而不是根据对象的类型来多态
- 与 Record + Sealed Class 配合,就能实现函数式语言中的"模式匹配 + 代数数据类型"组合拳
- 标志着 Java 开始从行为多态(OOP 的核心)向数据多态(函数式的核心)扩展
其他特性
| 特性 | 说明 | 范式意义 |
|---|---|---|
| Text Block | 多行字符串,"""...""" | 减少转义,声明式表达文本 |
| Helpful NPE | 精确告诉你哪个变量是 null | 调试体验改善 |
| ZGC 正式版 | 亚毫秒级 GC 停顿 | 为函数式风格的大量临时对象提供底层保障 |
范式定位
Java 17 是范式跃迁的起点——Record + Sealed + Pattern Matching 这"三驾马车",把函数式语言的核心数据建模能力搬进了 Java。Java 不再只是"OOP 语言加了点 Lambda",而是开始真正具备数据导向编程的能力。
6.5 Java 21(2023)—— 范式成熟与全面开花
Java 21 是 Java 8 以来最具革命性的版本。它不仅完成了模式匹配的最后一块拼图,还引入了虚拟线程——从根本上改变了 Java 的并发编程模型。
模式匹配正式化 + Record Pattern
// Record Pattern:解构记录类的字段
void printSum(Object obj) {
if (obj instanceof Point(int x, int y)) { // 直接解构出 x 和 y
System.out.println(x + y);
}
}
// 嵌套模式匹配
if (obj instanceof ColoredPoint(Point(int x, int y), Color c)) {
// 一层就解构到最内层
}
// switch + 类型模式 + 守卫条件(when)
String formatShape(Shape shape) {
return switch (shape) {
case Circle c when c.radius() > 10 -> "大圆形";
case Circle c -> "小圆形";
case Rectangle r -> "矩形: " + r.width() + "x" + r.height();
case Triangle t -> "三角形";
// 因为 Shape 是 sealed,编译器知道所有子类都覆盖了,不需要 default
};
}
范式意义:
- 模式匹配全面成熟——类型模式、记录模式、嵌套模式、守卫条件,函数式语言该有的基本都有了
- 穷举检查成为现实——sealed 类的 switch 不需要 default,编译器帮你检查是否覆盖所有情况
- 这是从"对象行为多态"到"数据结构匹配"的范式转换的完成标志
虚拟线程(Virtual Threads)—— Project Loom
字面意思:virtual = 虚拟的。虚拟线程是轻量级线程,由 JVM 管理而非操作系统,创建成本极低(可以轻松开百万个)。
// 以前:用线程池,小心翼翼控制数量
ExecutorService pool = Executors.newFixedThreadPool(100);
// 现在:每个任务一个虚拟线程,随便开
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 10_000; i++) {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1)); // 阻塞也不怕
return i;
});
}
}
范式意义:
- 这是并发编程范式的根本改变
- 以前:异步编程(CompletableFuture / Reactive)是为了"不阻塞线程"——因为线程太贵
- 现在:回归简单的同步阻塞编程——因为虚拟线程太便宜了,阻塞就阻塞呗
- 讽刺的是:函数式/响应式编程的一大动机(避免线程阻塞)被虚拟线程从底层消解了
- 这不是函数式的胜利,而是**"简单直接"的胜利**——用更简单的命令式风格就能写出高并发代码
结构化并发(Structured Concurrency)—— 预览
字面意思:structured = 结构化的。就像结构化编程(用 if/for/while 取代 goto)一样,把并发也结构化——子任务的生命周期被父任务严格约束。
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
Future<User> user = scope.fork(() -> findUser());
Future<Order> order = scope.fork(() -> fetchOrder());
scope.join(); // 等待所有子任务
scope.throwIfFailed(); // 任何一个失败就全部取消
// 两个都成功了才能到这里
return new Response(user.resultNow(), order.resultNow());
}
范式意义:
- 把并发从"散乱的线程"变成"有结构的代码块"
- 错误传播、取消、资源管理都变得可预测
- 这是并发编程的声明式化——你声明任务结构,运行时管执行细节
其他特性
| 特性 | 说明 | 范式意义 |
|---|---|---|
| Sequenced Collections | SequencedCollection / SequencedMap 接口 | 集合框架的统一,声明式表达"有顺序的集合" |
| String Templates(预览) | 字符串模板插值 | 声明式字符串构建 |
| Foreign Function & Memory API | 直接调用本地代码和操作堆外内存 | 取代 JNI,更安全、更声明式 |
| Generational ZGC | 分代 ZGC,性能进一步提升 | 为函数式风格的大量临时对象提供更强支撑 |
范式定位
Java 21 是范式成熟的里程碑:
- 数据建模层面:Record + Sealed + Pattern Matching 三件套正式完工,Java 具备了完整的代数数据类型能力
- 并发层面:虚拟线程 + 结构化并发,把 Java 的并发模型从"异步响应式"拉回"简单同步式"——但效率更高
- 总体方向:Java 正在变成一个多范式平衡的语言——OOP 仍是骨架,但函数式、数据导向、声明式的比重越来越大
6.6 演进轨迹总览
Java 8 (2014) Java 9 (2017) Java 11 (2018)
│ │ │
▼ ▼ ▼
Lambda + Stream 模块系统 + var +
函数式入门 集合工厂方法 HTTP Client
基础设施铺垫 过渡消化期
│ │ │
└──────────────────────┴──────────────────────┘
│
▼
Java 17 (2021)
│
Record + Sealed +
Pattern Matching
数据导向编程起点
范式跃迁开始
│
▼
Java 21 (2023)
│
模式匹配正式化 +
虚拟线程 +
结构化并发
多范式平衡成熟
七、总结与展望
7.1 核心洞察
Java 的演进有一个底层逻辑:
在不打破向后兼容的前提下,不断降低表达成本——让程序员用更少的代码、更清晰的意图表达,完成同样的事情。
这条线的方向是声明式:
- 变量类型让编译器推断(var)
- 数据类的方法让编译器生成(Record)
- 继承关系让编译器检查(Sealed)
- 并发调度让运行时管理(Virtual Thread)
7.2 Java 的独特道路
Java 不会变成 Haskell,也不会变成 Scala。它走的是自己的路:
一个务实的、渐进的、永远向后兼容的多范式演进之路。
它不追求纯粹,而是追求平衡与实用——在保留 OOP 主体的同时,不断吸收其他范式的优秀特性。
7.3 未来展望
下一个 LTS 是 Java 25(2025),预计会有:
- 值类型(Project Valhalla):基本类型的泛型化,消除装箱开销
- 更完善的模式匹配:更多模式类型、更强大的解构能力
- 结构化并发正式版:并发编程的新范式
范式迁移还在继续,Java 的多范式平衡之路还很长。
附录:参考资源
- 《设计模式:可复用面向对象软件的基础》—— GoF,理解 OOP 设计模式
- 《Java 核心技术卷》—— Cay S. Horstmann,Java 语言特性详解
- 《函数式编程思维》—— Neal Ford,从命令式到函数式的思维转换
- 《Java 并发编程实战》—— Brian Goetz,Java 并发编程经典
- OpenJDK 官方文档 —— https://openjdk.org/