升级 JDK17 那天晚上我们的分库分表服务一启动就直接抛了InaccessibleObjectException异常指向 ShardingSphere 的 Groovy 反射逻辑。当时一脸懵JDK8 跑得好好的为什么换到 JDK17 连 String 的私有构造器都不让碰了这个报错通常出现在使用 ShardingSphere 内联分片算法比如order_id % 12这种 Groovy 表达式的项目中尤其是你刚从 JDK8 或 JDK11 升级到 JDK17 之后。它跟你的业务代码没有直接关系也不是 ShardingSphere 用错了而是 JDK 模块化对反射访问收紧了规则。如果你正在升级 JDK17或者在新项目里配置 ShardingSphere 分片算法时遇到了同样的异常这篇文章应该能帮你彻底解决问题。我会从现象、根因、三种解决方案到排查技巧完整还原这次问题的处理过程尽量把底层原因讲清楚让你以后再遇到类似反射问题能够自己定位而不是只会复制网上的启动参数。1. 现象一次升级 JDK17 引发的反射异常1.1 报错现场那天的报错堆栈大致是这样的不同版本的行号可能略有差异但核心信息完全一致Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make private java.lang.String(byte[], byte[], int, int, boolean) accessible: module java.base does not opens java.lang to unnamed module at java.lang.reflect.ReflectAccess.checkCanSetAccessible(ReflectAccess.java:69) at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:199) at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:172) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:383) at org.codehaus.groovy.runtime.callsite.BytecodeDispatchedCallSite.call... at org.apache.shardingsphere.infra.algorithm.core.algorithm.ShardingSphereAlgorithmFactory... at org.apache.shardingsphere.sharding.algorithm.sharding.inline.InlineShardingAlgorithm...核心的一句话是Unable to make private java.lang.String(...) accessible: module java.base does not opens java.lang to unnamed module注意这里的String(...)是一个私有构造器不是我们平时写的new String(xxx)。Groovy 在执行脚本的某个内部环节试图通过反射调用这个私有构造器然后调用setAccessible(true)来绕过访问控制结果被 JDK17 拦了下来。我们的环境大致是这样的Spring Boot 2.7.x、JDK 17.0.6、ShardingSphere 5.1.x分片算法里写了不少 Groovy 表达式例如sharding: tables: t_order: actualDataNodes: ds_$-{0..1}.t_order_$-{0..11} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_id_mod shardingAlgorithms: order_id_mod: type: INLINE props: algorithm-expression: order_id % 12在 JDK8 下这套配置跑了大半年没有问题升级 JDK17 后应用启动或者第一次执行分片查询时就炸了。最开始我们怀疑是 ShardingSphere 版本太老但翻了一圈资料、做了几个实验之后发现真正的问题出在 JVM 对反射访问的限制上。1.2 问题触发的业务场景为什么这么多项目会遇到这个异常因为 ShardingSphere 的 INLINE 分片算法本质上就是用 Groovy 表达式计算路由目标。对于团队来说这种配置方式非常直观几行配置就能搞定按订单取模、按用户取模、按日期范围分表等需求。但 Groovy 是动态语言它的很多魔力都建立在反射之上而 JDK17 对反射的约束恰恰是所有版本里最严格的。这种约束对正常业务代码影响不大但对依赖setAccessible的第三方库就成了拦路虎。尤其像 Groovy 这种追求高性能脚本执行的框架在字节码生成、方法缓存、构造器调用等内部路径中都会尝试使用反射来提升效率。从 JDK8 升到 JDK17相当于原来一路绿灯的通道突然多了几道安检行李超标的全部拦下。虽然问题表现为 ShardingSphere 和 Groovy 的报错但其实不只是这两个组件。任何在 JDK17 上使用反射访问 JDK 内部非公有成员的 Java 库都可能触发InaccessibleObjectException。因此在解决这个问题之前先要搞清楚 JDK17 的模块化封装到底改了什么。2. 根因JDK 模块系统不背锅但 setAccessible 就是这个规矩2.1 JDK 从 9 开始搞的强封装Java 9 引入模块系统Project Jigsaw时把 JDK 自带的代码拆成了很多模块java.base是最核心的一个包含了java.lang、java.util、java.io这些基础包。模块系统的一个关键特性叫强封装模块内部的非public成员默认不能被模块外的代码反射访问。举个例子java.lang.String类的public方法大家随便用但它的私有构造器、私有字段以及包私有的内部实现都不再是“只要你反射就能碰”的。模块里的module-info.java如果没有通过opens关键字把某个包开放出去外部代码一旦调用setAccessible(true)就会抛出InaccessibleObjectException。JDK 9 到 JDK 16 其实还留了一个口子就是--illegal-accesspermit默认情况下允许部分反射访问只是会在日志中打警告。到了 JDK 17官方彻底收紧了策略--illegal-access启动参数被移除默认就是 deny。也就是说JDK 17 里你想反射访问 JDK 内部非公有成员唯一合规的途径是使用--add-opens或--add-exports明确开放对应模块和包。很多人一看到InaccessibleObjectException就骂框架不行其实这个锅 JDK 不背模块化设计是有意为之。真正的问题是 Groovy 这种历史悠久的动态语言库还残留着早期 JDK 下依赖反射访问内部 API 的代码路径。2.2 Groovy 为什么非要反射 String 私有构造器Groovy 执行order_id % 12这类表达式时并不是像我们想象的那样“解释执行”一遍就完它内部会经历脚本解析、AST 转换、动态调用点call site缓存甚至可能生成字节码。在这个过程中Groovy 为了优化字符串的构造和拼接会尝试调用 JDKString类里一些非公有的构造器。以报错信息里的private java.lang.String(byte[], byte[], int, int, boolean)为例这类私有构造器的作用是避免复制字节数组直接从已有数组中构造字符串。在 JDK8 时代第三方库通过反射调用这种构造器很常见因为性能好、又不会破坏字符串语义。但 JDK17 的模块强封装要求java.base/java.lang对反射代码所在的模块开放而 Groovy 运行在 classpath 上属于未命名模块unnamed module系统默认没有开放这个包的访问权于是setAccessible(true)直接失败。需要注意的是这个报错不一定每次都出在同一个构造器上也可能出现String(char[])、StringBuilder、MethodHandle等内部类的反射访问错误。但只要你走的是 Groovy 执行路径遇到java.base does not opens ... to unnamed module这类错误思路都是一样的找到报错指向的包用--add-opens把它开给未命名模块。2.3 为什么在 JDK8 没事在 JDK17 就炸这个问题的答案其实很直接。JDK8 没有模块系统反射访问setAccessible(true)可以突破几乎所有访问控制String的私有构造器想调就调。JDK9 到 JDK16 虽然有了模块系统但默认的--illegal-accesspermit还是给老库留了后门应用大概率能跑起来只是日志里会出现 “WARNING: An illegal reflective access operation has occurred” 这样的字眼很多人根本没注意。到了 JDK17后门彻底关闭之前所有“裸奔”的反射操作一次性爆发于是项目升级后第一天晚上就在工位上看到这个异常。这也解释了为什么网上很多资料告诉你“升级到 JDK17 后加两行 JVM 参数就好了”因为 JDK17 本质上是把非法反射访问从“警告”升级成了“异常”。它能通过参数放行但根因还是代码用了非公有成员的反射操作。所以我们要么给它开绿灯要么让它尽量不走这条路。3. 解决方案一加 --add-opens快速止血3.1 确定需要开放哪个包在解决这个问题的第一步先不要急着抄网上的一大堆参数。正确的做法是先看异常信息里的这一行module java.base does not opens java.lang to unnamed module它已经很明确地告诉你java.base模块下的java.lang包没有向未命名模块开放。那我们只需要在启动命令里加上--add-opens java.base/java.langALL-UNNAMED这个参数的意思是把java.base模块里的java.lang包通过opens的方式授权给所有未命名模块也就是运行在 classpath 上的代码包括你的应用和第三方依赖。这样一来Groovy 再想反射访问String的私有构造器就不会被模块系统拦截了。添加参数后的启动命令长这样java --add-opens java.base/java.langALL-UNNAMED \ -jar order-service.jar注意--add-opens是 JVM 启动参数不是应用参数必须放在-jar之前。如果你把参数写到-jar后面Spring Boot 会把它当成应用参数JVM 根本不会读取问题自然还在。3.2 不同环境的落地方式实际操作中我们很少直接用手敲命令启动 Java 服务通常是在 IDE、Shell 脚本、Docker 或者 Kubernetes 里配置。每种环境的写法稍微有点区别但底层逻辑完全一样。IDEA 中配置在 IDEA 里运行 Spring Boot 应用时打开 Run Configuration找到 VM options 一栏填入--add-opens java.base/java.langALL-UNNAMED然后保存重新启动。这里最容易踩的坑是有人把它填到了 Program arguments 里。这两个字段作用完全不一样Program arguments 是传给main方法的VM options 才是传给 JVM 的。Shell 启动脚本如果你的服务是通过 Shell 脚本启动的可以把参数放到JAVA_OPTS环境变量里export JAVA_OPTS--add-opens java.base/java.langALL-UNNAMED java $JAVA_OPTS -jar order-service.jar这样做的好处是将来要增加其他--add-opens参数只需要修环境变量不用动启动脚本。Docker 容器在 Dockerfile 中建议通过环境变量传入ENV JAVA_OPTS--add-opens java.base/java.langALL-UNNAMED ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app/order-service.jar]有些精简镜像不用 Shell 作为入口而是直接用java -jar启动那你在镜像里定义环境变量后JVM 是读不到JAVA_OPTS的必须让 Shell 做一次解析。这里我们采用sh -c的方式就是为了让环境变量能正常展开。Kubernetes 部署在 Kubernetes 中最常见的做法是通过env注入JAVA_OPTSenv: - name: JAVA_OPTS value: --add-opens java.base/java.langALL-UNNAMED然后在镜像的启动命令中和上面 Docker 示例一样用 Shell 去解析JAVA_OPTS。如果你用的是云厂商自带的启动脚本通常已经做了这个处理但部署后建议先看一眼 Pod 的启动命令确认参数真的传到了 java 进程上。3.3 能否只对目标包 opens而不是 ALL-UNNAMED理论上--add-opens语法中目标模块可以写具体的模块名比如--add-opens java.base/java.langcom.example.mymodule但这种情况要求你的代码已经模块化运行在 modulepath 而不是 classpath 上。绝大多数 Spring Boot 应用都是平铺的 classpath第三方依赖和你自己的代码都属于未命名模块没有具体模块名可写所以实际场景中几乎都用ALL-UNNAMED。需要注意的是开放包意味着同一个模块里的所有未命名代码都可以通过反射访问该包的非公有成员。在安全敏感的场景下这种开放范围确实变大了。但短期的止血目标是为了让服务能在 JDK17 上跑起来这个代价通常可以接受。如果你实在不放心可以等应用稳定后用后面要讲的 Java 自定义分片算法方案逐步替换掉 Groovy 脚本减少对 JVM 参数的依赖。4. 解决方案二升级依赖版本根上解决4.1 框架版本的迭代方向加--add-opens只是让 Groovy 能绕过模块系统的检查并没有消灭问题源头。如果团队不愿意长期维护一堆 JVM 参数可以考虑升级依赖版本。ShardingSphere 从早期版本开始一直在适配新 JDK尤其是 JDK17 发布后社区对模块化带来的反射限制做了不少调整。如果你当前用的是比较老的版本可以先尝试升级到较新的稳定版然后看发布说明里有没有提到 JDK17 兼容性相关内容。具体升级目标版本以你在用的产品线为准我这边不推荐盲目追最新版因为升级框架本身有回归风险。你可以先在一个独立的测试环境验证启动时看是否还出现InaccessibleObjectException。不过说实话依赖版本升级并不总是能彻底解决问题因为 ShardingSphere 内部下层的 Groovy 版本也可能需要联动升级框架本身未必能完全屏蔽底层脚本库的反射行为。因此升级版本通常只能缩小问题范围未必能让你完全不加任何 JVM 参数。4.2 Groovy 版本的调整ShardingSphere 的 INLINE 分片算法依赖 Groovy 来解析表达式。Groovy 自身对 JDK17 的适配情况直接影响这个异常的触发概率。Groovy 3.0 之后的版本对 JDK9 的模块系统支持逐步增强到 Groovy 4.0 以后对 JDK17 的兼容性明显更好。如果你的项目是 Maven 管理可以用依赖树命令看看当前实际使用的 Groovy 版本mvn dependency:tree -Dincludesorg.codehaus.groovy:groovy如果发现某个老版本的 Groovy 是罪魁祸首可以尝试在 POM 中显式覆盖版本。比如手动引入更高版本的 Groovydependency groupIdorg.codehaus.groovy/groupId artifactIdgroovy/artifactId version4.0.24/version /dependency但这里必须提醒你跨版本替换 Groovy 要非常谨慎因为 ShardingSphere 可能依赖 Groovy 的某些内部行为新版不一定 100% 兼容。改完以后一定要回归测试分片算法、脱敏算法、鉴权等所有用到脚本的功能模块。4.3 升级后的回归检查无论升级 ShardingSphere 还是 Groovy都不能只看应用能不能启动。分片算法的逻辑正确性直接关系到数据路由稍有不慎订单数据就可能被写到错误的表里。建议回归时至少覆盖以下几点启动阶段算法工厂能否正常加载所有配置的 INLINE 表达式有没有报错。分片正确性准备一组覆盖所有分片键边界值的数据比如订单 ID 为 0、1、11、12、999核对路由到的实际数据节点是否符合预期。查询验证分别测试插入、查询、批量查询、跨分片查询确认结果集正确。压力测试用和生产相近的 QPS 压一下观察是否因为 Groovy 版本变化带来额外的性能损耗。升级版本不是简单换坐标而是一次完整的兼容性验证。如果升级后问题解决了那当然是好事如果问题依旧再回头找 JVM 参数也不迟。5. 解决方案三绕开 Groovy 脚本改用 Java 代码分片5.1 为什么可以绕开在经历过这次报错之后我认真思考了一个问题项目里用了那么多分片算法真正需要 Groovy 这种动态表达能力的有几个其实大部分场景不过是取模、哈希、时间范围这些用 Java 写一个类也就是几十行代码的事。与其被 JVM 参数和框架版本绑着手脚不如直接把分片算法改成 Java 代码从根上避开反射问题。ShardingSphere 支持自定义分片算法你可以定义一个类实现相应的算法接口然后在分片配置中通过类名引用。这样 Groovy 就不再参与分片表达式的执行自然不会再碰String私有构造器的反射路径。5.2 示例代码自定义分片算法下面这个例子按订单 ID 取模路由到 12 张表。不同版本的 ShardingSphere 接口略有差异我这里以常见版本为参考你落地时以自己使用的版本 API 为准。public class OrderIdModShardingAlgorithm implements StandardShardingAlgorithmLong { Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueLong shardingValue) { long orderId shardingValue.getValue(); long index orderId % availableTargetNames.size(); for (String targetName : availableTargetNames) { if (targetName.endsWith(_ index)) { return targetName; } } throw new IllegalArgumentException( 未找到可用的分片目标, orderId orderId ); } }然后在配置中指定该算法shardingAlgorithms: order_id_mod: type: CLASS_BASED props: strategy: standard algorithmClassName: com.example.demo.OrderIdModShardingAlgorithm表策略保持原来的引用即可tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: order_id_mod这段代码的关键在于从availableTargetNames中筛选出后缀匹配_0到_11的数据节点返回真实存在的表名。如果你的物理表命名不是t_order_0这种规则只要把命名规则对齐算法逻辑是不变的。5.3 对比 Groovy 内联表达式与 Java 编码的取舍在团队里推动用 Java 替换 Groovy 之前最好先做一次系统对比避免架构评审时被挑战。我自己梳理过一张对照表维度Groovy 内联表达式Java 自定义算法开发效率配置一行非常快需要写类、编译、部署运行性能脚本解析 反射调用纯方法调用无额外开销JDK17 兼容需要 JVM 参数或新版 Groovy天然兼容无反射限制可维护性配置散落在 YAML 中难测试类代码容易单测和 Code Review动态场景支持复杂动态表达式灵活改逻辑需要重新发版从这个表格能看出来Groovy 的优势更多在“简单快捷”上Java 自定义算法的优势在“稳定可控”上。如果你的分片逻辑几十年如一日的简单比如就是id % N我建议直接 Java。如果确实需要频繁调整复杂规则且团队能接受维护这些 JVM 参数继续用 Groovy 也未尝不可。6. 踩坑记录与排查技巧6.1 一个参数不够还报其他 InaccessibleObjectException第一次解决这个问题时我只加了--add-opens java.base/java.langALL-UNNAMED应用确实跑过了String私有构造器那个坎但没多久又在别的地方炸了出来报错变成了module java.base does not opens java.util to unnamed module后来又陆续遇到了java.lang.reflect、java.text、java.math这几个包的问题。原因很简单Groovy 脚本执行涉及的反射面非常广不只String构造器一个点。随着应用运行到不同代码路径其他包的反射访问也会被模块系统拦截。网上常见的组合参数长这样--add-opens java.base/java.langALL-UNNAMED --add-opens java.base/java.lang.reflectALL-UNNAMED --add-opens java.base/java.utilALL-UNNAMED --add-opens java.base/java.textALL-UNNAMED --add-opens java.base/java.mathALL-UNNAMED但我不建议一上来就加全套而是要看实际报错信息精准添加。每次报错都会明确告诉你哪个包没开你就加哪个包加到应用稳定为止。这样虽然多迭代几次但分析过程和最终结论会是清晰的以后出了问题也能快速定位。6.2 检查 JVM 参数是否生效经常有同事跑来问我“我明明加了--add-opens怎么还是报一样的错”每次我让他先看一眼 Java 进程实际收到的启动参数大部分情况下都能发现问题出在参数位置或者部署脚本覆盖上。检查当前 Java 进程参数最直接的方式是使用jcmdjcmd 进程PID VM.command_line如果是本地调试也可以在应用启动后追踪系统属性。你可以在 Spring Boot 启动类里临时加一段把实际生效的 JVM 参数打出来System.out.println(ManagementFactory.getRuntimeMXBean().getInputArguments());这两个方法能帮你确认参数到底有没有真正传给 JVM。还有一个常见的坑是容器平台在启动时会拼接自己的JAVA_OPTS可能把你自定义的参数覆盖掉这时候只能到 Pod 的启动命令或容器日志里排查。6.3 安全横评不要为了省事开放所有包网上确实有一些“万能脚本”让你把所有包全部 open 一遍。方便是方便但会对安全边界造成不必要的破坏。JDK 模块化的目的之一就是防止第三方库随意反射 JDK 内部状态。如果你放开所有包等于把这道门彻底拆了万一某个依赖被攻击攻击者就有机会通过反射操作 JDK 内部对象风险等级完全不一样。我的建议是能少开就少开能不开就不开。--add-opens是解决兼容性问题的临时工具不是常规配置。在正式环境里应该对启动参数做审计明确记录每一项开放的模块和包是用来解决什么问题的。这样将来某天升级了依赖某个参数不再需要了可以及时清理掉避免长期暴露不必要的风险面。另外加参数可以解决 Groovy 的问题但项目里如果还有其他依赖也在做类似反射操作它们的问题不会自动消失。所以最好的策略是一边用参数止血一边推进版本升级和代码改造多管齐下而不是把希望全寄托在那一行命令上。最后再分享一个实战体会我现在已经习惯把所有 JVM 参数集中放到配置中心管理然后在发布流程里增加一步参数快照比对。每次发版后自动对比这次启动参数和上一次的差异一旦发现某个--add-opens被吞掉或者新增了一个奇怪的 open 路径就能立刻发现。踩过几次坑之后我觉得这套机制比让每个开发人肉记忆 JVM 参数要靠谱得多。JDK17 是个转折点认真对待反射兼容问题比加一百个临时参数都更实际。
复杂度详解)
