§1 版本元数据

Java 8 是 Java 历史上最重要的一次版本迭代，函数式编程语法与现代化集合操作的引入让它成为真正意义上的"分水岭"——之前的 Java 是纯面向对象，之后的 Java 既能面向对象又能函数式。截至 2025 年，Java 8 仍是国内中小厂线上 JVM 的大多数版本，地位无可撼动。

我个人的版本印象：Java 8 是 2014 年 3 月正式 GA，发布前我还在用 Java 6/7 写 SSH 框架，Lambda 出来后整个 Java 社区像被按下了加速键，一年内 Spring 5、Guava 21、JUnit 5 全部跟进，函数式写法彻底渗透进每一个开源项目。

§2 重大新特性

2.1 Lambda 表达式（JEP 126）

问题：在 Java 7 及以前，“把一段行为作为参数传递"是件很痛苦的事——你得先写一个内部类（new Runnable() { ... }），或者写一个 Comparator 实现类，写 5 行只为了塞一行 return a - b;。匿名内部类啰嗦到劝退新人。

方案：Lambda 表达式让函数式接口（只有一个抽象方法的接口）的实例化变成”->“箭头后的简洁语法，编译器根据目标类型自动推断参数类型和返回值。

代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 旧写法：匿名内部类
Runnable r1 = new Runnable() {
    @Override public void run() { System.out.println("hello"); }
};

// 新写法：Lambda
Runnable r2 = () -> System.out.println("hello");

// 排序
List<Integer> nums = Arrays.asList(3, 1, 4, 1, 5, 9, 2, 6);
nums.sort((a, b) -> a - b);

收益：代码行数缩减 50%~80%，可读性大幅提升；为 Stream API 铺路，没有 Lambda 就没有 Stream。

2.2 Stream API（JEP 107 / 335）

问题：对一个集合做"过滤+转换+汇总"是后端代码里 90% 的活，但 Java 7 时代只有 for 循环 + 临时 ArrayList，每加一步就要再加一层循环、再加一个 List 变量，代码可读性迅速崩塌。

方案：Stream API 把"数据源 + 中间操作 + 终止操作"串成一条管道，链式调用让数据流向一目了然；底层用 fork-join 框架可透明地切并行。

代码：

1
2
3
4
5

List<String> upper = names.stream()
    .filter(n -> n.length() > 4)
    .map(String::toUpperCase)
    .sorted()
    .collect(Collectors.toList());

收益：业务代码量减半，“filter/map/collect"让意图直接显形；parallelStream() 还能免配置地利用多核 CPU，但需谨慎使用（详见 §7 坑 1）。

2.3 Optional

问题：NullPointerException（NPE）常年霸榜 Java 异常榜首——返回 null 是 Java API 设计的"原罪”，调用方不知道什么时候该 null check，往往在最深处的调用栈上爆雷。

方案：java.util.Optional<T> 是一个"值可能存在也可能不存在"的容器，通过 of / empty / ofNullable 三种工厂方法构造，用 map / flatMap / filter 做链式处理，最后用 orElse / orElseGet / orElseThrow 三选一收尾。

代码：

1
2
3
4

String name = repo.findByIdOpt(1)
    .map(User::getName)
    .filter(n -> n.length() > 0)
    .orElse("anonymous");

收益：把"是否可能为空"从运行时 NPE 提升到编译期类型检查，调用方被迫决定"空值怎么办”；可读性 10 倍提升。

2.4 java.time（JEP 150）

问题：java.util.Date 是可变对象（非线程安全）、月份从 0 开始（Calendar.JANUARY = 0）、SimpleDateFormat 不是线程安全的、Date 的 getYear() 返回的是"1900 起的偏移量"——这个 API 设计堪称反面教材教科书。

方案：JSR-310 全新 java.time 包，所有类不可变且线程安全；LocalDate / LocalTime / LocalDateTime 处理"人读得懂的时间"，Instant 处理"机器读得懂的时间戳"，ZonedDateTime 处理带时区时间，DateTimeFormatter 替代 SimpleDateFormat 且线程安全。

代码：

1
2
3
4
5
6

LocalDate today = LocalDate.now();
LocalDate birthday = LocalDate.of(1990, Month.JANUARY, 15);
long days = ChronoUnit.DAYS.between(birthday, today);  // 距今天数

// 格式化（线程安全）
String s = today.format(DateTimeFormatter.ISO_LOCAL_DATE);

收益：消灭了 90% 的时间相关 bug；和数据库 JDBC java.sql.Timestamp 互转 API 完善；Duration / Period 让"两个时间点差多少"成为一行代码。

2.5 Default Method

问题：Java 接口从 1.0 起就规定"所有方法必须被实现类实现"，这导致一旦给接口加方法，所有实现类都要改——Collection 接口不能动就是这个历史包袱。

方案：接口里可以有 default 修饰的方法，带方法体；实现类可以不重写，直接继承默认实现。

代码：

1
2
3
4
5
6
7
8

public interface MyList<T> extends List<T> {
    // 不破坏现有实现类，平滑新增能力
    default List<T> filter(Predicate<T> p) {
        List<T> result = new ArrayList<>();
        for (T t : this) if (p.test(t)) result.add(t);
        return result;
    }
}

收益：让接口演化成"加方法不必改所有实现"成为可能，是 Stream API 能加在 Collection 上的关键——Collection.forEach() / stream() / spliterator() 都是 Java 8 借 Default Method 加进 Collection 的，老实现类零修改即可获得新能力。

2.6 Method Reference（:: 操作符）

问题：Lambda 体内经常就是一行"调用某个已存在的方法"，比如 n -> System.out.println(n) 其实就是把参数转给 println——Lambda 本身是"套壳"。

方案：:: 方法引用是 Lambda 的语法糖，编译器把 ClassName::method 翻译为等价的 Lambda。

代码：

1
2
3

names.forEach(System.out::println);     // 等价于 n -> System.out.println(n)
names.stream().map(String::toUpperCase); // 等价于 s -> s.toUpperCase()
names.stream().map(User::getName);      // 等价于 u -> u.getName()

收益：行数再减 30%，意图更清晰（“我就是要用这个现成方法”）；IDE 重构时自动把 Lambda 转 Method Reference。

§3 JVM 参数变更

Java 8 的 JVM 参数最值得记住的变化都围绕"PermGen 移除"和"G1 引入"展开。永久代时代，-XX:PermSize 和 -XX:MaxPermSize 是几乎所有调优文档的必填项；Java 8 之后这两个参数被废弃，相应的元数据从堆内存搬到了本地内存（native memory），由 Metaspace 接管。这个变化的副作用是：Metaspace 默认只受本地内存限制，不像 PermGen 还有堆上限兜底——一旦类加载器泄漏（典型场景：OSGi、热部署、Tomcat 重新部署），Metaspace 会一直涨直到撑爆物理内存。

启用 G1（实验性）：

1

java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 MyApp

我遇到的真实坑：升级 Java 8 后忘了调 -XX:MaxMetaspaceSize，结果服务运行三个月后把机器 32G 物理内存吃光了——Metaspace 默认只受本地内存限制，不像 PermGen 还有堆上限兜底。生产环境必加 -XX:MaxMetaspaceSize=512m。另一类参数是 Lambda 内部实现：Java 8 引入 invokedynamic 字节码指令，Lambda 编译时并不生成额外的 class 文件，而是通过 LambdaMetafactory 在运行时动态绑定——这也是为什么 Lambda 几乎没有启动开销。调优 Metaspace 一定要顺带监控 jstat -gcmetacapacity <pid> 的 MCMX/MCMN 字段，Metaspace 增长曲线和 PermGen 时代判读方法一致。

§4 垃圾回收器演进

Java 8 的 GC 工具箱在版本史上属于"承上启下"——Serial、Parallel、CMS 三位老将还在服役，G1 终于从 7u4 的实验性"升职"到正式可用，但还没拿到默认 GC 的位子（要等 Java 9）。我刚接触 Java GC 时，Parallel 是教科书示例——多线程回收、新生代复制算法、老年代标记-整理，适合"后台批处理"这种吞吐优先的场景；G1 则是"分 Region 的增量回收器"，目标是把 STW 暂停控制在 200ms 内，适合 Web/在线交易等延迟敏感场景。

重大变化：移除 PermGen（永久代），用 Metaspace 替代——Metaspace 用本地内存（native memory），不再受 JVM 堆限制。-XX:MaxPermSize 弃用，-XX:MaxMetaspaceSize 取而代之。这一变化让"动态类加载"的框架（OSGi、热部署）摆脱了 OutOfMemoryError: PermGen space 的噩梦，但代价是要主动管理 Metaspace 上限。

调优示例：

1
2
3
4
5

# Metaspace 调优（避免本地内存无限增长）
java -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m MyApp

# G1 调优（实验性，但比 Parallel 暂停时间短）
java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 MyApp

Java 8 的 GC 选型建议：吞吐优先选 Parallel（默认）；低延迟需求才上 G1（且要接受吞吐小幅下降）；CMS 已开始出现"碎片化"问题，建议 Java 11 后淘汰。Java 9 之后 G1 才正式成为默认 GC，Java 11 又出了 ZGC（实验）和 Epsilon，Java 8 时代的 GC 工具箱相比之下显得单薄。我个人排查 GC 问题的固定动作：先用 jstat -gc <pid> 1s 看每秒 Eden/Survivor/Old 的增减节奏，再用 jmap -histo:live <pid> 触发 Full GC 抓内存里的大对象，最后 jhat 或 VisualVM 打开 heap dump 看 GC Roots 引用链——这套组合拳 80% 的内存泄漏都能定位。

§5 生产代码实战

光看语法不够，必须落到代码上才有体感。我挑了两个最常见的生产场景做对比演示——一个是集合操作（Stream vs for），一个是空值处理（Optional vs null check）。两个 demo 都用 javac --release 8 编译通过，OpenJDK 8+ 都能跑。

Demo 1：Stream vs 旧式 for 循环对比

文件 assets/code/jdk-lts/Java-8/StreamVsLoopDemo.java：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;

public class StreamVsLoopDemo {
    public static void main(String[] args) {
        List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "Dave");

        // 旧写法：for 循环 + 临时 List
        List<String> upper1 = new java.util.ArrayList<>();
        for (String n : names) {
            if (n.length() > 4) {
                upper1.add(n.toUpperCase());
            }
        }
        System.out.println("for 循环: " + upper1);

        // 新写法：Stream
        List<String> upper2 = names.stream()
            .filter(n -> n.length() > 4)
            .map(String::toUpperCase)
            .collect(Collectors.toList());
        System.out.println("Stream:   " + upper2);
    }
}

跑通命令（Windows PowerShell）：

1
2
3

cd assets/code/jdk-lts/Java-8
javac --release 8 StreamVsLoopDemo.java
java StreamVsLoopDemo

实际输出（过滤长度大于 4 的名字）：

1
2

for 循环: [ALICE, CHARLIE]
Stream:   [ALICE, CHARLIE]

对比观察：旧写法 7 行（含临时 List 初始化），新写法 5 行但意图直白——filter 过滤、map 转换、collect 收集，读者扫一眼就知道"取长名字大写"。可读性的提升远大于代码行数的缩减。在团队 Code Review 时我经常拿这个例子说服同事"Stream 不是装 X，是真的让代码更易读"。

Demo 2：Optional 防 NPE

文件 assets/code/jdk-lts/Java-8/OptionalNpePreventionDemo.java：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import java.util.Optional;

public class OptionalNpePreventionDemo {
    public static void main(String[] args) {
        UserRepository repo = new UserRepository();

        // 旧写法：null check + NPE 风险
        User u1 = repo.findById(1);
        String name1 = u1 != null ? u1.getName() : "anonymous";
        System.out.println("旧写法: " + name1);

        // 不存在的 ID
        User u2 = repo.findById(999);
        try {
            String name2 = u2.getName();  // 抛 NPE
            System.out.println("不存在的: " + name2);
        } catch (NullPointerException e) {
            System.out.println("NPE 抛了！这就是 Optional 要解决的痛点");
        }

        // 新写法：Optional 防 NPE
        String name3 = repo.findByIdOpt(1).map(User::getName).orElse("anonymous");
        System.out.println("Optional: " + name3);

        String name4 = repo.findByIdOpt(999).map(User::getName).orElse("anonymous");
        System.out.println("Optional 不存在: " + name4);
    }
}

class User {
    private final Long id;
    private final String name;
    public User(Long id, String name) { this.id = id; this.name = name; }
    public Long getId() { return id; }
    public String getName() { return name; }
}

class UserRepository {
    public User findById(long id) {
        if (id == 1) return new User(1L, "Alice");
        return null;  // 模拟"没找到"
    }
    public Optional<User> findByIdOpt(long id) {
        if (id == 1) return Optional.of(new User(1L, "Alice"));
        return Optional.empty();
    }
}

跑通命令：

1
2

javac --release 8 OptionalNpePreventionDemo.java
java OptionalNpePreventionDemo

实际输出：

1
2
3
4

旧写法: Alice
NPE 抛了！这就是 Optional 要解决的痛点
Optional: Alice
Optional 不存在: anonymous

对比观察：旧写法需要 5 行样板代码（null check + try-catch），NPE 仍然在运行时爆；新写法把"找不到"在类型层面表达出来，编译器强制你处理"空"的情况。这才是 Optional 真正的价值——让"可能为空"成为接口签名的一部分，调用方不能再忽略这个事实。生产中我会强制要求团队 Repository / Service 层返回 Optional<T> 而不是 T（可能为 null），让"空值处理"在 Code Review 阶段就被强制讨论。

两个 demo 联起来看：Stream + Optional + Method Reference + Lambda 四件套在生产代码里基本是"成对出现"的——Repository 返回 Optional<User>，Service 用 userOpt.map(this::enrich).filter(Objects::nonNull).orElse(defaultUser) 链式处理，最后 .stream() 出来交给下游。这套组合让"数据从数据库到 UI"的全链路代码可读性跨一个台阶。这也是为什么我经常在团队内部推"新项目一律 Java 8+"——语言层的设计哲学直接影响代码质量。

§6 升级指南

从 Java 7 升到 Java 8 算是"无痛升级"——字节码格式从 51 升到 52 但 class 文件结构无破坏性变更，源代码基本不需要改。但有几个"暗坑"必须提前踩一遍。

从 Java 7 升 Java 8：

回滚预案：保留 JDK 7 路径，灰度切流；先用 jdeps 工具扫描依赖确认没有用到 Java 8 移除的 API；上线后用 jstat -gcmetacapacity <pid> 监控 Metaspace 使用量。升级前要做的三件事：(1) 用 jdeps --jdk-internals app.jar 扫描 JAR 包，看是否有依赖 sun.* 内部 API——这些代码需要替换或加 --add-opens 兼容；(2) 全量跑回归测试，重点关注反射 / 动态代理 / 类加载器相关路径；(3) 在预发环境压测 GC 日志，对比 Java 7 和 Java 8 的暂停时间和吞吐差异。

我个人升级踩过的坑：从 Java 7 升 Java 8 时，CGLIB 动态代理在 Java 8 上跑了一周后开始报 IllegalArgumentException: Superclass has no null constructors but no arguments were given——根因是 -parameters 编译选项默认变了，Jackson 反序列化需要这个选项。升级前确认所有用到反射的库（Jackson / Gson / CGLIB）都对参数名解析友好。另一个隐蔽的坑是 sun.misc.Unsafe——Java 8 开始对 Unsafe 的反射调用增加了更多限制，部分 Netty / HBase 场景需要加 JVM 参数放行。升级完成后的稳定期监控（上线 1~2 周）建议每 6 小时检查一次 GC 日志、Metaspace 曲线、Full GC 频率——很多 PermGen 时代的"启动慢、Full GC 多"在 Java 8 上会变成"Metaspace 缓慢泄漏"，症状换了根因没变。

§7 踩坑实录

1. parallelStream() 陷阱 —— 共享可变集合导致 race condition。parallelStream 看似能加速，但遇到共享 ArrayList 写入就 NPE 或数据丢失：list.parallelStream().forEach(sharedList::add) 永远不要写。生产中慎用 parallelStream，优先用 ExecutorService 显式控制并发；真要并行就用 Collectors.toConcurrentMap 之类的并发收集器。

2. Optional 在 Java 8 不能序列化——Optional 实现没有 Serializable，DTO / RPC 字段用 Optional 会爆 NotSerializableException：class UserDto { private Optional<String> nickname; } 序列化时直接报错。DTO 字段用 Optional 的习惯从 Java 8 一直要改到 Java 11+（即便新版本仍需注意兼容性）；领域对象内部用 Optional，对外传输转成普通字段或 null。

3. Lambda 闭包变量必须是 effectively final —— Lambda 体内不能修改外部局部变量。int sum = 0; list.forEach(n -> sum += n); 编译报错 “Variable used in lambda expression should be final or effectively final”。要么用 AtomicInteger（并发友好），要么改用 reduce / collect（声明式）：int sum = list.stream().mapToInt(Integer::intValue).sum();。

4. Stream 里的 checked exception 难处理 —— Stream 的 map / forEach 等方法签名是 Function<T, R> / Consumer<T>，不允许抛 checked exception。如果集合里的元素处理逻辑会抛 IOException，比如 list.stream().forEach(this::saveToFile) 编译会报错 “Unhandled exception: java.io.IOException”。三种对策：(1) 在方法内 try-catch 后包成 RuntimeException 抛出；(2) 自己定义一个 ThrowingFunction 函数式接口继承 Function 加上 throws Exception；(3) 用 Lombok 的 @SneakyThrows（不推荐，掩盖了异常传播链）。生产中我倾向方案 (1) —— 把 checked 转 unchecked 时显式记录日志再抛，比静默吞掉或粗暴 @SneakyThrows 更可控。

§8 下一篇预告

下一站 Java 11（2018-09-25 发布）—— HTTP Client 标准化、var 类型推断、字符串新方法、单文件源运行、ZGC 实验登场。详见 Java 11 LTS 深度解读。