国产化与信创 Java

• 国内常用与国产 JDK 的定位与来源
• 特性与增强的差异
• 选型依据

国产 JDK 基于 OpenJDK 上游，各自带工程增强。Azul Zulu 是 Azul 发行的 OpenJDK 构建，含 C4（Concurrent Continuously Compacting）低延迟 GC 等特性，企业支持成熟。Alibaba Dragonwell（龙井）基于 OpenJDK，针对阿里大规模业务优化，提供协程（Wisp）、增强的 GC 与诊断工具，大促场景经验丰富。Tencent Kona 基于 OpenJDK，腾讯优化，提供 KonaFiber（协程）等特性，适配腾讯云生态。Huawei BiSheng（毕昇）基于 OpenJDK，华为优化，聚焦鲲鹏（ARM）架构的性能与适配，提供毕昇 JVM 增强。OpenAnolis（龙蜥）是操作系统发行版，其 JDK 面向龙蜥 OS 生态。工程差异体现在：GC 增强、协程支持、ARM 架构优化、诊断工具、供应链与支持服务。选型应结合芯片架构（ARM/X86）、云生态、特性需求与支持服务。

国产 JDK 差异在"定制增强"与"生态适配"：Dragonwell 强在阿里规模、Kona 强在腾讯/云、BiSheng 强在鲲鹏 ARM、Azul 强在低延迟与支持。选型要匹配芯片与生态。

• JIT 与 GC 的差异
• 诊断工具的差异
• 线上问题排查方法

国产 JDK 与 OracleJDK 在 JIT、GC 与诊断工具上有差异。JIT 方面：国产 JDK 基于 OpenJDK 的 C2/Graal，可能加入针对特定架构（ARM）或业务场景的优化，如 Dragonwell 的编译优化、Kona 的 AI 场景优化。GC 方面：国产 JDK 提供增强 GC，如 Dragonwell 的改进 G1/ZGC、Kona 的协程与 GC 协同、外资品牌 Azul 的 C4 低延迟 GC（非国产），与 Oracle 默认 GC 行为可能不同。诊断工具：国产 JDK 常自带增强工具（如 Dragonwell 的 ToolBox、Kona 的诊断工具、BiSheng 的调优工具），提供更多在线诊断能力。线上排查：先确认版本与特性差异，用 JFR/诊断工具采集 GC、JIT、线程、内存数据，对比基准与上线差异，定位到 JIT/GC 行为不同导致的性能问题，必要时切换 GC 或调参。注意国产 JDK 的协程/特性可能改变线程模型，排查需结合其自有工具。

国产 JDK 与 Oracle 的差异主要在"定制增强"，排查时需先确认版本差异，再结合其自有诊断工具与标准 JFR 数据分析，避免用 Oracle 的经验盲目套用。

• 信创适配的完整链路
• 芯片/OS/JDK 的兼容矩阵
• 验证方法与流程

信创适配的完整链路包括：应用代码 → 依赖库 → 国产 JDK → 国产 OS → 国产 CPU（硬件底座）。兼容矩阵需覆盖芯片（鲲鹏/飞腾/龙芯等，ARM 与 X86/龙芯 LoongArch 等不同架构）、OS（麒麟/统信等，可能为 Linux 的国产发行版）、JDK（对应架构的国产 JDK 构建）的组合。验证方法：1) 环境矩阵——在目标芯片/OS/JDK 组合上构建环境；2) 编译与运行验证——确认字节码、JNI、依赖库在该架构可运行；3) 功能回归——全量功能测试；4) 性能验证——压测对比不同架构下的吞吐/延迟/GC；5) 指令集与字节序验证——确认 CPU 指令集支持、字节序一致（Java 字节码与平台无关，但 JNI/原生库需适配）；6) 兼容性工具——用 JDK 兼容性测试、jdeps 检查。关键是将"架构、OS、JDK"做成可重复的矩阵测试，分阶段推进。

信创适配的核心是"跨架构、跨 OS、跨 JDK 的兼容矩阵验证"：Java 本身的平台无关性降低了适配难度，但 JNI、原生库、指令集与 OS 差异仍需逐项验证。

• JNI 与原生库的兼容性
• 字节码的平台无关性
• 指令集与 CPU 架构差异

信创项目中 Java 生态依赖的兼容性评估需分层考虑。字节码：Java 字节码与平台无关，javac 编译的 .class 可在任意架构运行，但字节码版本（class file）需与 JDK 兼容，这是主要风险（版本不匹配）。JNI：依赖 JNI 的原生库（如加密、图像、解压库）需针对国产 CPU 架构（ARM、LoongArch、X86）重新编译，否则 UnsatisfiedLinkError；需确认原生库是否提供对应架构的构建。指令集：CPU 架构差异（ARM vs X86 vs LoongArch）影响 JIT 代码生成与某些指令（如 SIMD/向量指令），部分库可能利用特定指令集需适配。OS 差异：国产 OS 的库版本、系统调用、文件系统可能与预期不同。评估方法：梳理依赖清单，标注原生库与架构，在目标环境逐项验证，用 jdeps 检查内部 API 依赖，并确认第三方库是否有对应架构版本。

兼容性评估的核心是"区分字节码友好与原生依赖"：字节码几乎无障碍，JNI/指令集/OS 才是真正的适配点。逐项梳理依赖并验证是评估的关键。

• 各国产芯片的架构背景
• JVM 兼容性测试
• JVM 性能测试方法

国产芯片覆盖不同架构：鲲鹏（ARM）、飞腾（ARM）、海光（X86）、兆芯（X86）、申威（SW64/自研）。JVM 兼容性测试：确认 JDK 提供对应架构的构建，运行标准兼容性测试（如 TCK 子集、自测脚本）验证字节码执行、JIT、GC、JNI 正常。性能测试方法：用基准测试（如 SPECjbb、Renaissance、Dacapo）与业务压测，对比不同芯片/架构下的吞吐、延迟、GC 表现；关注 JIT 在 ARM 上的代码生成质量、SIMD 向量化、GC 停顿与内存带宽。需在同构容器环境、控制变量下对比，并针对特定架构调优（如 ARM 的分配、GC 线程数）。测试还覆盖稳定性（长时运行、故障注入）与多核可扩展性。对申威等自研指令集，需重点验证 JDK 与工具链的适配完整性。

国产芯片测试的关键是"架构认知 + 兼容性 + 性能基准"：ARM/X86 较成熟，自研指令集（申威）需重点验证适配。性能测试需控制变量、多基准联合评估。

• JDBC 驱动替换
• SQL 方言差异
• 分页与自增主键适配

国产数据库替换 MySQL 需适配多个层面。JDBC 驱动：达梦用 dm.jdbc.driver.DmDriver、人大金仓（KingbaseES）用 com.kingbase8.Driver、openGauss 用 org.opengauss.Driver、OceanBase 兼容 MySQL 协议可复用 MySQL 驱动，需替换驱动类与连接 URL。SQL 方言：各库对数据类型、函数、限定符、JSON 支持的方言不同，如达梦的 ROWNUM/LIMIT、金仓的 LIMIT、openGauss 对 PostgreSQL 方言的侧重，需改写兼容 SQL。分页：MySQL 用 LIMIT offset, size，达梦/金仓多支持 LIMIT 或 ROWNUM，openGauss 支持 LIMIT，需统一分页 SQL 或使用 ORM 分页插件。自增主键：MySQL 用 AUTO_INCREMENT，达梦用 IDENTITY/序列、金仓用 IDENTITY/序列、openGauss 用 SERIAL/序列，需适配主键生成方式与 getGeneratedKeys 行为。工程上推荐用 ORM（MyBatis/JPA）方言抽象 + 数据库方言配置，减少硬编码 SQL。

数据库替换的适配核心是"驱动、方言、分页、主键"四类，用 ORM 方言抽象可降低适配成本。关键是先做 SQL 扫描与方言差异清单，再逐项改写。

• 国密算法 SM2/SM3/SM4 的特点
• BouncyCastle 的接入
• 国产密码模块与合规

国密算法包括 SM2（非对称加密/签名）、SM3（哈希）、SM4（对称加密），是国标商用密码算法。Java 接入方式：1) BouncyCastle——通过注册 BouncyCastleProvider 提供 SM2/SM3/SM4 支持，使用 JCE 标准接口（Cipher、Signature、MessageDigest），开发便捷、跨平台，但需注意其合规性；2) 国产密码模块（如无恒/方正/三未信安等厂商的硬件加密机/加密卡、或基于国密算法的安全组件）——提供硬件级密钥管理与国密运算，满足更严格的合规要求。合规要点：商用密码应用安全性评估（密评）要求使用符合国标（GB/T 32918 等）的算法实现，关键场景需硬件密码模块存密钥；接入时需配置 Provider 优先级、密钥管理与算法标识符合国标。选型上，一般业务用 BouncyCastle 快速接入，合规要求高的场景用国产密码模块。

国密接入的取舍是"开发便捷 vs 合规强度"：BouncyCastle 便捷但不满足硬件级合规，国产密码模块满足密评但成本高。按业务合规要求选型。

• 各 JDK 的协程特性
• GC 增强
• 信创适配侧重

国产 JDK 在协程、GC 与信创适配上有差异。协程：Alibaba Dragonwell 提供 Wisp（协程），Tencent Kona 提供 KonaFiber（协程），用于在平台线程上实现用户态协程，提升高并发 IO 场景吞吐；BiSheng 主要聚焦 JVM 基础性能。GC：Dragonwell 提供针对大规模应用的 GC 增强（改进 G1/ZGC），Kona 与腾讯业务结合优化 GC，BiSheng 针对鲲鹏架构优化 GC 与内存。信创适配：BiSheng 深度适配鲲鹏（ARM）架构，是华为信创生态重要组件；Dragonwell 与 Kona 也支持 ARM 与信创 OS。差异核心：协程是可选的并发增强，GC 优化侧重不同，信创适配侧重不同芯片生态。选型需结合 CPU 架构、并发需求与生态。

国产 JDK 差异在"协程增强、GC 优化、信创架构侧重"：Dragonwell/Kona 强在协程，BiSheng 强在鲲鹏适配。理解差异才能按需选型。

• 不同 CPU 架构的字节序
• JIT 支持与架构差异
• 性能调优

国产 CPU 架构差异影响 Java 运行。字节序：鲲鹏/飞腾（ARM）与龙芯（LoongArch）均为小端（little-endian），与主流 X86 一致，Java 字节码是平台无关的，字节序差异主要在 JNI/原生库与数据读写场景，需确认原生库的字节序处理。JIT 支持：JVM 的 C2/Graal JIT 需为各架构生成机器码，ARM 与 LoongArch 的 JIT 代码生成、向量化（SIMD）支持不同，高端 JIT 优化（如 AVX）在 ARM 上对应 NEON 等指令，需确认 JDK 对目标架构的 JIT 优化成熟度。性能调优：测量不同架构下的 GC、JIT、分配表现，调整堆、GC 线程数、JIT 编译阈值；ARM 上关注内存带宽与缓存，LoongArch 上关注 JIT 与工具链成熟度。调优需用基准测试定位架构特有瓶颈，而非套用 X86 经验。

国产 CPU 上的 Java 差异主要在"JIT 代码生成与架构特性"：字节序基本一致，JIT 与向量化是主要差异点。调优需针对架构实测，避免套用 X86 经验。

• TongWeb 与 Tomcat 的定位
• 兼容性验证要点
• 迁移适配

东方通 TongWeb 是国产 Java 应用服务器（中间件），与开源 Tomcat 定位相近，但作为信创中间件需满足国产化与合规要求。适配验证要点：1) Servlet/Jakarta EE 规范兼容——确认应用使用的 Servlet 版本、JSP、WebSocket 等能力在 TongWeb 上支持；2) 部署结构——TongWeb 的部署目录、war 结构、上下文配置与 Tomcat 的差异；3) 配置项——连接池、超时、线程池、SSL 等配置项的映射；4) 日志与监控——TongWeb 的日志格式、指标接口与 Tomcat 的差异；5) 第三方库——Spring Boot 内嵌 Tomcat 应用需改为外置部署到 TongWeb，或用 TongWeb 的 Spring Boot 适配。迁移做法：先在预发环境做功能回归、性能对比与兼容性测试，重点验证 Session、JSP、过滤器、WebSocket。

信创中间件适配的核心是"规范兼容 + 部署/配置差异"：TongWeb 遵循 Jakarta EE 规范，但部署方式与配置项不同。验证需覆盖功能、性能与部署形态。

• 国密 TLS（TLCP）与 GB/T 38636
• Java 中的实现方式
• 合规场景

国密 TLS（TLCP，国密安全传输协议，对应 GB/T 38636）在标准 TLS 基础上增加国密算法套件（SM2/SM3/SM4），用于加密通信的国密化。Java 实现方式：1) 使用支持国密套件的 JSSE Provider（如 BouncyCastle 的 JSSE 支持、或国产厂商的 JSSE Provider），配置国密 TLS 套件与密钥；2) 使用国产密码模块/加密机进行证书与密钥管理；3) 通过 OpenSSL 的国密支持 + Java 侧对接。实现需配置国密证书（SM2 签名证书/加密证书）、算法套件（如 ECC_SM4_CBC_SM3）、CipherSuite 映射。合规场景：政务、金融、运营商等需满足密评要求的系统，要求 TLS 使用国密算法；需在服务端与客户端均配置国密 TLS，并做兼容性降级（国密与标准 TLS 并存）。合规上需通过密评检测，使用符合 GB/T 的算法实现。

国密 TLS 是"通信加密的国密化"，实现关键是"国密算法套件 + 国密证书 + JSSE Provider 配置"。合规场景多为密评要求，需端到端支持并做兼容降级。

• 信创全栈组件
• 端到端迁移流程
• 验证与回归

信创全栈集成了国产 OS（OpenEuler）、国产 JDK、国产数据库与国产中间件，Spring 应用迁移需端到端验证。流程：1) 环境准备——在 OpenEuler + 国产 JDK（对应架构）搭建基础环境；2) 依赖适配——替换数据库驱动与中间件部署方式，适配 SQL 方言；3) 应用部署——Spring Boot 应用适配国产 JDK 与中间件（外置部署或内嵌）；4) 端到端验证——全链路功能测试（登录、业务、事务、异步）、性能压测（吞吐/延迟/GC）、稳定性（长时运行、故障恢复）；5) 数据一致性——验证事务、缓存、连接池在国产数据库下的行为；6) 观测量——监控（JVM、GC、连接池、中间件指标）是否正常。关键点是"分层验证 + 全链路回归"：先逐组件验证，再端到端联调，最后做专项（并发、事务、安全）验证。

信创全栈迁移的核心是"端到端验证"而非单点替换：各组件（OS/JDK/数据库/中间件）单独验证后，必须做全链路联调与性能/稳定性回归，才能确保生产可用。

• 中间件与容器的适配
• 国产 K8s 发行版的差异
• 性能验证方法

信创环境下中间件与国产 K8s 发行版（如原厂 OpenShift 国产化、麒麟容器、统信 K8s 等）的适配包括：1) 镜像——中间件镜像需在国产 OS/架构（ARM 等）上可构建运行，基础镜像与依赖需适配；2) 资源限制——中间件需感知 cgroup 限额（内存/CPU），避免 OOM 或限流；3) 存储与网络——PV/CSI、CNI 网络在国产 K8s 的兼容性，如需用国产存储与网络插件；4) 探针与生命周期——就绪/存活探针、优雅下线与中间件生命周期配合。性能验证方法：在国产 K8s 上部署中间件，做压测（吞吐/延迟/连接数）、对比宿主机与容器网络延迟、验证 GC 与资源自适应、监控限流与 OOM。重点是"容器化适配 + 国产组件兼容 + 性能对比"。

中间件容器化适配的关键是"在国产 OS/架构/网络/存储上可运行且性能达标"：镜像适配、资源感知、网络存储兼容是主要适配点，性能验证需对比容器与裸机。

• CPU 指令集兼容性
• 国产 OS 适配
• 中间件适配验证

信创环境 Java 兼容性验证需覆盖多层。CPU 指令集：确认 JDK 与依赖原生库在目标架构（ARM/LoongArch/X86）上可用，验证 JIT 代码生成、向量指令（SIMD）、字节序等相关行为；某些库可能依赖特定指令集，需确认适配。国产 OS：验证 JDK 在国产 OS（麒麟/统信/OpenEuler）上的运行、系统库兼容、文件系统/权限/时区/编码行为，以及 OS 的补丁与安全策略与 JDK 的兼容。中间件适配：应用服务器（Tomcat/东方通）、连接池、消息队列等中间件在国产 OS/架构上的可用性与性能，验证部署、配置、日志与监控。验证方法：搭建目标环境矩阵，逐组件做功能与性能验证，全链路回归，重点覆盖加密、网络、序列化、文件操作等易受 OS/架构影响的点。

信创 Java 兼容性是多层验证：指令集影响 JVM 与原生库，OS 影响运行环境，中间件影响部署。分层验证 + 全链路回归是确保兼容性的系统方法。

• 组合矩阵的构建
• 兼容性测试范围
• 测试策略

信创 Java 生态兼容性测试的核心是构建"组合矩阵"：将 JDK 版本（不同国产 JDK）、中间件（Tomcat/东方通/消息队列）、组件（Spring、ORM、连接池、加密库）与 OS/架构（麒麟/统信，ARM/X86）组合成矩阵。测试范围：每个组合的编译/运行、功能回归、配置兼容、性能对比，以及 JNI/原生库在组合下的可用性。策略：1) 用"全矩阵 + 抽样"结合——关键组合全测，低风险组合抽样；2) 建立基线组合（如某 OS/架构/JDK/中间件的黄金组合）主测，其他组合做差异验证；3) 自动化——用 CI 编排矩阵测试，产物可追溯；4) 优先级——按业务使用频率与风险排序组合。目标是在覆盖风险与成本间平衡，支撑选型决策。

组合矩阵测试的关键是"广度与成本平衡"：全量组合成本高，需用基线组合 + 抽样 + 自动化覆盖。矩阵化让兼容性结论可量化、可追溯。

• 兼容清单的建立
• 版本与特性差异
• 回归策略

Oracle JDK 迁移到国产 JDK 需建立兼容清单并做回归。兼容清单包括：1) 版本比对——确认国产 JDK 的 Java 版本（如 8/11/17/21）与 Oracle 一致，字节码版本兼容；2) 特性差异——检查国产 JDK 的额外特性（协程、GC 增强）与默认行为差异，以及是否移除/精简某些 Oracle 专有功能；3) 依赖与原生库——确认 JNI、第三方库在国产 JDK 上的可用性；4) 启动参数与 JVM 参数——验证 -XX 参数、GC、JIT 参数在国产 JDK 上的支持；5) 诊断工具——确认 JFR、jcmd 等工具可用。回归策略：先在预发环境做全量功能回归 + 性能对比（GC/JIT/启动时间），再灰度上线；重点回归序列化、反射、加密、并发与 GC 行为。分阶段迁移，保留回滚。

JDK 迁移的关键是"兼容清单 + 差异化回归"：先核对版本与特性差异，再验证依赖与参数，最后做功能与性能回归。灰度与回滚保障迁移安全。

• JCE Provider 机制
• BouncyCastle 的国密支持
• 接入方式

Java 侧通过 JCE（Java Cryptography Extension）Provider 机制支持算法。BouncyCastle 提供 BouncyCastleProvider，注册后可通过 Cipher、Signature、MessageDigest 等标准 API 使用 SM2（非对称/签名）、SM3（哈希）、SM4（对称）。接入方式：Security.addProvider(new BouncyCastleProvider())，然后以 "SM4"、"SM3"、"SM2" 作为算法名调用标准接口。也可用国产厂商的 JCE Provider（提供硬件级密钥管理）。工程要点：Provider 优先级（多个 Provider 时算法选择）、密钥材料格式（SM2 公钥/私钥的 X.509/PKCS#8 处理）、SM2 的签名与加密模式（C1C3C2 等）、以及国密证书的读取。BouncyCastle 便捷但需合规评估，硬件场景用国产 Provider。

国密算法接入依托 JCE 抽象：JCE 提供标准接口，BouncyCastle 提供国密实现，注册 Provider 即可使用。理解 Provider 与算法名映射是接入基础。

• 双跑（并行运行）
• 灰度发布
• 回退机制与风险

信创替换应分步迁移以控制风险。双跑（双写/并行）：新旧系统并行运行，数据双写或请求分流，验证新旧系统结果一致，发现差异及时调整，降低切换风险。灰度：按比例/按用户/按模块逐步放量到新系统，观察指标（功能、性能、稳定性），确认无误再放量。回退：保持旧系统可用，具备一键回退能力，切换失败时快速回退到旧系统，避免业务中断。信创替换风险包括：兼容性问题（驱动/方言/中间件）、性能差异（新组件性能不达标）、数据一致性问题（双写不一致）、以及依赖与工具链缺失。风险控制：先做详尽的兼容性验证与压测，建立风险清单与回退预案，分阶段小步快跑，监控全链路指标。

信创迁移的核心是"小步快跑 + 可回退"：双跑验证一致性、灰度控风险、回退保可用。风险识别与预案是迁移成功的关键。