kkFileView 文件在线预览 JDK 选型指南：信创环境下 JDK 8 与 JDK 11 如何选-平芜编程栈

kkFileView 文件在线预览 JDK 选型指南：信创环境下 JDK 8 与 JDK 11 如何选

【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView

kkFileView 是一款基于 Spring Boot 的文件在线预览服务，做国产化部署时，JDK 8 还是 11？这个选择直接影响改造成本与运行稳定性。本文先给结论式选型速查，再讲项目当前版本现状与 3 个国产化适配点，最后附可照做的部署清单，3 分钟内可确定选哪个 JDK、怎么落地。

📋 选型速查：三类场景，一张表定方案

场景	推荐 JDK	一句话理由
存量系统已在 JDK 8、不想升级	JDK 8	选官方声明支持 JDK 8 的发布线，运行时环境不动，回归成本最低
性能敏感、高并发预览业务	JDK 21（至少 11）	新一代 GC 算法压缩停顿时间，大文件转换高峰更平稳
新建项目	JDK 11（或 21）	11 为 LTS，安全补丁周期长；21 与当前仓库编译基线一致，少做一轮兼容验证
长期维护系统、3 年内有升级计划	JDK 11	迁移成本一次性花掉，后续不再二次升级 JDK

在国产化存量系统且 JDK 8 的场景下，留在 8 更合适，因为变量只有 kkFileView 的发布版本，操作系统与中间件都不动；在新建信创机房的场景下，JDK 11 或 21 更合适，因为没有存量兼容包袱，可直接选国产 JDK 的 11 及以上发行版。

🧾 版本现状核对：编译用 JDK 21，不等于你必须用 21

pom.xml 声明了项目的编译基线：

<java.version>21</java.version> <maven.compiler.source>${java.version}</maven.compiler.source> <maven.compiler.release>${java.version}</maven.compiler.release> <maven.compiler.target>${java.version}</maven.compiler.target>

java.version是编译期参数，决定构建出的字节码版本与源码可用的语言特性；真正决定"生产服务器必须用哪个 JDK"的，是每个发布版本发布说明中声明的最低运行 JDK。例如当前 5.0.0 基于 Spring Boot 3.5.6，运行时最低要求 Java 17，官方 Docker 基础镜像自带 openjdk-21-jre；而较早的 4.x 发布线可在 JDK 8 上运行。也就是说：源码仓库编译版本高，不代表存量 JDK 8 系统必须先升级——选哪个发布版本，才决定用哪个 JDK。

🔧 三个国产化适配点：字体、缓存、跨平台

1. 内置中文字体。中文文档在国产化 Linux 上预览乱码、缺字，多数是系统字体缺失。基础镜像 docker/kkfileview-base/Dockerfile 直接把字体打进镜像：

ADD fonts/* /usr/share/fonts/chinese/

同一镜像在不同国产机型上，同一份文档的预览结果保持一致，不需要逐台补装字体。

2. 缓存实现可切换。application.properties 中缓存类型只有一行配置：

cache.type = ${KK_CACHE_TYPE:jdk}

默认jdk（JVM 内存缓存，无外部依赖）；多实例部署时用环境变量KK_CACHE_TYPE=redis切成 Redis 缓存即可。选型时 JDK 版本与缓存实现解耦，不必绑定。

3. Windows / Linux 跨平台。仓库内附 Windows 版 LibreOfficePortable（server/LibreOfficePortable/），Linux 侧使用基础镜像，同一套配置文件两端通用。信创机型（麒麟、UOS 等均为 Linux 内核）与存量 Windows 节点之间切换，只需换转换组件与运行环境，不用改预览参数。

🎯 按场景选型：三套判断条件

存量系统：不动 JDK，只动发布版本

系统 JDK 为 8、本年度升级计划不含 Java → 留在 8，选最后一条官方声明支持 JDK 8 的发布线（4.x 系列），以发布说明为准
预览并发低（单机并发转换低于几十），文件以文本、PDF 为主 → JDK 8 内存占用更小，适配硬件紧张的旧机器
出现以下任一情况再升 11：并发转换任务经常超过 50，或需要用 JDK 9 之后才有的 GC 参数调停顿

性能敏感场景：按并发量定 11 或 21

单实例高并发（并发转换大于 50）或大文件转换高峰明显 → JDK 21，ZGC 可把停顿时间压到毫秒级
中等并发、内存预算低于 8G → JDK 11，G1 的混合回收调节空间够用，且国产发行版（Dragonwell、毕昇等）在 11 上最成熟
在相同压测数据下，JDK 8 的 GC 可调参数更少，高峰 Full GC 频次通常更高，11/21 的调优余量更大

新建系统：直接 11 起，能上 21 就上

部署当前 5.0.0 构建产物：需要 JDK 17+，建议直接 21，与 pom.xml 编译基线一致，少一次兼容验证
国产 JDK 可选毕昇、Dragonwell、腾讯 Kona，11 / 17 / 21 均有对应版本，按单位信创准入目录采购
3 年内有上云或换机计划 → 不要选 8，避免 JDK 迁移做两遍

✅ 部署落地清单：5 步照做

核对运行时与发布版本匹配：java -version对照所选发布线的最低 JDK 要求；部署 5.0.0 时使用 JDK 17+（推荐 21）。
检查缓存：确认cache.type默认值jdk符合预期；多实例部署前设置KK_CACHE_TYPE=redis并验证连接，再启动服务。
检查字体并抽验：裸机 Linux 部署先安装中文字体（文泉驿等），再抽验一份中文 Word 和一份 PPT，确认无乱码、缺字；使用官方 Docker 镜像可跳过此步。
配置 GC 与内存监控：开启 GC 日志，按-Xmx的 85% 设置告警；上线首周关注 Young GC 频率与 Full GC 次数。
准备回滚预案：旧版本 jar 与配置文件保留在备用目录，一键重启切回并抽验预览，确认正常后再清理旧文件。