从 Java 迁移到 Clojure

「把 Java 项目迁到 Clojure」这句话里藏着三个完全不同的问题：技术能不能迁（几乎总是能，JVM 是同一台虚拟机）、架构该怎么切（这才是难点）、团队能不能接住（决定成败）。多数失败的迁移不是败在语法，而是败在「一次性重写」的冲动和「用 Java 的思维写 Clojure」的习惯。本文按「决策 → 路径 → 边界 → 构建 → 团队 → 陷阱 → 验收」的顺序，给出一条可落地的渐进迁移路线。

1. 迁移决策：该不该迁、迁多少

1.1 迁移动机的分辨

先分清动机是技术性还是组织性：

1.2 三种迁移模式

结论几乎是唯一的：除非系统小到几天能重写，否则一律走绞杀者模式。 它的最大价值是「每一步都可回退」。

1.3 成本模型

迁移成本 ≈ 重写成本 × 1.5（双跑与切换）+ 团队学习成本 + 长期的「双语维护成本」。最后一项最容易被低估：只要还有 Java 代码，团队就得同时维护两套心智模型、两套构建、两套监控习惯。

1.4 三种反模式

• 大爆炸重写：停掉所有需求开发，集中三个月重写。现实是需求不会停，重写必然延期，最后两边都烂尾。
• 边写边学：让完全不懂 Clojure 的人直接写核心业务，产出会是一堆「Java 味的 Clojure」，后期重构成本高于重写。
• 无限期双语：迁移启动后再也没结束，团队长期背负两套栈。因此必须有明确的「迁移完成」定义与时间盒。

2. 渐进式改造路径

2.1 绞杀者模式落地

[客户端] → [路由/网关]
              ├── 旧路径 → Java 服务
              └── 新路径 → Clojure 服务

关键在于路由层：它决定了哪些流量走新实现。可以从 HTTP 路由、消息 topic、定时任务三个维度分别切。

2.2 从「无状态边缘」切入

最佳的第一块试验田具有这些特征：

• 无状态：不需要处理会话与共享内存；
• 边界清晰：输入输出是数据，不是对象图；
• 非核心：出问题不影响主线业务；
• 高频改动：能快速体现新语言的生产力。

典型候选：BFF/聚合层、报表导出、数据清洗 ETL、Webhook 接收器、内部工具 API。

2.3 领域模型的迁移顺序

领域逻辑最难，建议按「数据 → 纯函数 → 服务」三步走：

1. 先把 Java 的 DTO/实体映射成 Clojure map，只做读写，不碰逻辑；
2. 把无副作用的计算逻辑抽成纯函数，逐个搬迁并补测试；
3. 最后才处理状态与副作用（数据库、外部调用），把它们收敛到边界。

这样每一步都可验证，且中间态是可运行的。

2.4 切入点排序实战

一个可参考的迁移顺序（由易到难）：

第 6 步最容易被跳过。只要旧代码还在，双语维护成本就一直在。迁移计划里必须包含「删除清单」。

3. 互操作边界设计

3.1 边界放在哪

一条原则：边界要窄且稳定。不要在两个语言之间传递复杂的对象图，而是传递扁平的、可序列化的数据（map / vector / 基本类型）。对象图跨界会同时引入互操作细节和耦合。

互操作本身的语法细节（gen-class、proxy、deftype、type hint）已有系统梳理，见 Clojure 调用 Java 深度实践 。本节关注边界的架构选择。

3.2 Java 调用 Clojure

两种主流方式：

;; 方式一：把 Clojure 函数暴露为 Java 接口（reify 实现接口，供 DI 注入）
(ns app.service
  (:import [app.api UserService]))

(defn make-user-service []
  (reify UserService
    (findUser [_ id]
      ;; 返回 Java 可消费的结构
      (let [u (fetch-user id)]
        (java.util.HashMap. {"id" (:id u) "name" (:name u)})))))

;; 方式二：gen-class 生成真正的 Java 类（需要 AOT）
(ns app.handler
  (:gen-class
   :name app.Handler
   :methods [[handle [String] String]]
   :main false))

(defn -handle [_ s] (str "handled: " s))

选择依据：如果 Java 侧通过接口/DI 调用，用 reify 最轻；如果需要被框架按类名反射加载（如 Servlet、Spring 的组件扫描），才需要 gen-class。

3.3 Clojure 调用 Java

(ns app.legacy
  (:import [com.legacy OrderService Order]))

(defn orders-for [^OrderService svc ^String user-id]
  ;; type hint 消除反射，跨边界调用务必加
  (->> (.listOrders svc user-id)
       (map (fn [^Order o] {:id (.getId o) :amount (.getAmount o)}))
       (into [])))

跨边界必加 type hint：不加会走反射，高频调用下性能损失可达数倍。

3.4 跨界的数据语义

三个必须显式约定的点：

• null vs nil：Java 的 null 进 Clojure 就是 nil，但 Clojure 的 nil 回到 Java 仍是 null。集合里的 nil 尤其危险，建议在边界统一过滤或转成 Optional/哨兵值。
• 可变性：Java 集合是可变的，Clojure 集合不可变。跨边界时立刻转成不可变（into []、into {}），否则后续代码会因外部修改而出现诡异 bug。
• 异常：Clojure 的 ex-info 是 RuntimeException 子类，能被 Java 捕获；反向则要注意受检异常（checked exception），Clojure 里不强制捕获，容易漏。

4. 混合构建与部署

4.1 Maven / Gradle + deps.edn

三种混合方式，按耦合度递增：

Maven 里用 clojure-maven-plugin 或 leiningen 的 :java-source-paths；Gradle 用 gradle-clojure 插件。工具链的完整对比见 Clojure 工具链演进 。

4.2 AOT 与 uberjar

;; deps.edn：声明 AOT 命名空间
{:paths ["src" "resources"]
 :deps  {...}
 :aliases
 {:build
  {:extra-paths ["classes"]
   :main-opts ["-m" "app.build"]}}}

;; app/build.clj
(ns app.build
  (:require [clojure.tools.build.api :as b]))

(defn uber []
  (b/delete {:path "target"})
  (b/copy-dir {:src-dirs ["src" "resources"] :target-dir "target/classes"})
  (b/compile-clj {:basis (b/create-basis {:project "deps.edn"})
                  :src-dirs ["src"]
                  :class-dir "target/classes"
                  :ns-compile '[app.core app.handler]})   ; gen-class 必须 AOT
  (b/uber {:class-dir "target/classes"
           :uber-file "target/app.jar"
           :basis (b/create-basis {:project "deps.edn"})
           :main 'app.core}))

要点：

• 只有需要 gen-class 或提前编译的命名空间才 AOT，全量 AOT 会让构建变慢、启动变慢；
• uberjar 启动时 JVM 参数（堆、GC、-XX:+UseZGC）通过 JAVA_OPTS 或容器启动脚本传入；
• 如果 Java 侧是 Spring Boot 的可执行 jar，Clojure 代码作为依赖打进 BOOT-INF/lib 时要注意类加载器隔离。

4.3 灰度与回滚

路由层要支持按比例/按用户切流：

(defn route [req]
  (if (canary? req)          ; 例如 5% 用户或内部账号
    (proxy-to :clojure-svc req)
    (proxy-to :java-svc req)))

回滚必须是「改一个开关」而不是「重新部署旧版本」。这一点决定了迁移能否安全推进。

4.4 配置与依赖的对齐

混合部署时最琐碎的坑在配置：

• 依赖版本漂移：Java 侧用 Maven BOM 管版本，Clojure 侧用 deps.edn。同一份 jackson 或 netty 必须锁到同一版本，否则会出现 NoSuchMethodError。做法是在 deps.edn 里显式 :override-deps 对齐。
• 配置来源统一：两边都从环境变量读配置，避免「Java 读 yaml、Clojure 读 EDN」的双轨。
• 时区与字符集：容器里统一 TZ=UTC 与 -Dfile.encoding=UTF-8，否则日期与中文会出现只在一边复现的 bug。

;; deps.edn：对齐被 Java 侧 BOM 锁定的版本
{:deps {com.fasterxml.jackson.core/jackson-databind {:mvn/version "2.17.2"}}
 :aliases
 {:prod {:override-deps {org.clojure/clojure {:mvn/version "1.12.0"}}}}}

5. 团队技能与代码评审

5.1 能力矩阵

培训的关键不是讲语法，而是重建思维模型：从「对象 + 方法」转到「数据 + 函数」，从「赋值」转到「变换」。

5.2 代码评审关注点

Java 工程师写 Clojure 最常见的五个问题：

1. 用 def 存可变状态：(def counter 0) 然后 (set! ...)——应改用 atom/ref 或直接返回新值；
2. 到处 loop/recur：多数循环用 map/reduce/->> 更清晰；
3. 过度使用 let 与临时变量：Clojure 鼓励表达式组合，而非语句序列；
4. 把 map 当「无类型对象」：应配合 spec/Malli 定义结构，避免「字符串键的字典到处传」；
5. 异常控制流：用 try/catch 处理业务分支，而非返回结构化结果。

评审清单可以固化成团队规范，配合 Clojure 代码规范与格式化 的工具链自动检查。

5.3 防止「用 Java 写 Clojure」

一个有效手段是强制数据导向：要求所有跨模块接口传递的是 map/vector，而不是自定义类型。当接口是数据时，函数自然是纯的，测试自然好写。

6. 迁移中的常见陷阱

6.1 可变状态与并发

Java 的 synchronized 思维会诱导在 Clojure 里写锁。正确姿势是优先用不可变数据 + atom/swap!，只有真正需要协调多资源时才用 ref 或 locking。

6.2 性能回归

三个高频原因：

• 反射：跨边界未加 type hint；
• 装箱：数值密集计算未用 ^long/^double 或 deftype 原生字段；
• 惰性序列叠加：多层 map/filter 未用 transducer 或 into 收敛，导致对象分配暴增。

性能优化的系统方法可参考 Clojure 性能优化与 GraalVM 。但要注意顺序：先保证正确与可读，再做基准测试，最后才优化热点。

还有一类隐形回归是启动时间：Clojure 默认不 AOT，启动时要做类加载与命名空间初始化，冷启动可能比 Java 慢。对延迟敏感的 Serverless 场景，要么 AOT，要么用 GraalVM native image 把启动压到毫秒级。

6.3 调试与可观测断层

两套技术栈意味着两套日志、两套 APM、两套 trace 上下文。迁移期间必须保证：

• trace id 跨界传递（HTTP header 或消息头）；
• 日志格式统一（都输出结构化 JSON）；
• 指标命名统一（同一业务指标不因实现语言而改名）。

否则线上排障会变成「在两种工具里来回跳」。

6.4 测试策略的平移

Java 侧的单元测试不能直接搬，因为被测单元从「类」变成了「函数」。平移策略：

• 纯函数：直接调用断言，几乎零成本；
• 有副作用的服务：把副作用抽象成协议或函数参数，测试时注入 stub；
• 集成测试：保留原有的 HTTP/DB 集成测试，只把实现换成 Clojure 版本；
• 属性测试：对数据处理逻辑尤其有效，用生成器覆盖边界输入。

Clojure 的测试生态与 Java 差异较大，建议在迁移早期就建立测试基线，避免「没有测试所以不敢改」的死结。

6.5 组织层面的陷阱

技术之外，还有两类高频翻车：

• 只有一两个人会 Clojure：这个人一旦离职或休假，迁移停摆。缓解方式是结对 + 轮换，确保至少 3 人能独立提交。
• 评审缺位：早期 Clojure 代码没人能评，质量失控。可以引入外部评审或结对评审，把「Java 味」在合并前挡掉。

7. 验收与度量

迁移不能只看「代码写完了」，要有可量化的验收标准：

其中「双跑比对」是最有说服力的验收手段：同一份输入同时喂给新旧实现，比对输出，差异为零才允许切流。

双跑比对的一个实操细节：输出比对要先归一化（排序 map 键、统一数值精度、忽略时间戳），否则会因为无意义的格式差异产生大量假阳性，最终没人再认真看报告。

8. 小结

从 Java 迁到 Clojure，技术不是瓶颈，节奏和边界才是：

• 动机要真：并发与领域复杂度是理由，「更酷」不是；
• 路径要渐进：绞杀者模式 + 从无状态边缘切入，每步可回退；
• 边界要窄：传数据不传对象图，跨边界必加 type hint，跨界即转不可变；
• 构建要统一：AOT 只给需要的命名空间，灰度与回滚靠开关；
• 团队要陪跑：培训重建思维模型，评审清单防「用 Java 写 Clojure」；
• 验收要量化：双跑比对 + 性能与稳定性不劣化。

迁完一轮回头看，你会发现真正的收获不是「换了个语言」，而是领域模型被数据化了——这恰恰是 Clojure 最持久的价值。