📅 2026-06-10 | 🏷️ Java, Lambda, JVM | 📖 阅读约 15 分钟

问题起源

做 Java ORM 的时候，更让人羡慕的就是 C# 的 LINQ：

// C# — 直接写 Lambda，框架自动转 SQL
var users = await context.Users
    .Where(u => u.Age > 18 && u.Name == "Tom")
    .OrderBy(u => u.Id)
    .ToListAsync();

我们也想在 Java 里这么写：

// 理想中的 Java ORM 写法
query.where(u -> u.getAge() > 18 && u.getName().equals("Tom"));

但试了一下就发现，Java 运行时核心拿不到 Lambda 里面的结构。u -> u.getAge() > 18 这个表达式，运行时只能执行它（传一个 User 进去，返回 true/false），但拿不到"age > 18"这个结构信息。

📅 2026-06-10 | 🏷️ ASM, 字节码, Javac Plugin, JVM | 📖 阅读约 30 分钟

前言

上一篇的两种方案（SerializedLambda、APT）有一个共同的限制：不能解析 Lambda 表达式，只能解析方法引用。

// ✅ 能解析 — 方法引用，有明确的方法名
Getter<User, Integer> getter = User::getAge;

// ❌ 不能解析 — Lambda 表达式，方法名是 "lambda$main$0"
Predicate<User> p = u -> u.getAge() > 18;

这一篇的两种方案可以直接解析 u -> u.getAge() > 18，但代价是需要深入 JVM 底层。

方案 3: ASM 字节码分析

原理

Lambda 表达式编译后，编译器会生成一个私有静态方法，这个方法包含了 Lambda 的实际逻辑。比如：

📅 2026-06-10 | 🏷️ JVM, 性能, JMH, JDK | 📖 阅读约 20 分钟

前言

前四篇实现了五条 Lambda 解析路线。这一篇用 JMH 在三个 JDK 版本上跑基准测试，看看：

1. 五条路线的性能差距到底有多大？
2. JDK 升级对性能有多大影响？
3. 实际使用中应该怎么选？

测试环境

硬件: macOS ARM64 (Apple Silicon)
JDK 8:  BellSoft Liberica JDK 8u422 (aarch64)
JDK 17: Homebrew OpenJDK 17.0.19
JDK 26: Homebrew OpenJDK 26.0.1
JMH:    1.37

JMH 参数：

• Fork = 2（2 个 JVM 进程，避免 JVM 特异性）
• Warmup = 5（5 轮预热）
• Measurement = 8（8 轮测量）
• Mode = AverageTime（平均耗时，越小越好）

重要前提：缓存

实际使用中，所有框架都会缓存解析结果。