ServiceLoader.reload() 不会重新加载 SPI 实现类，仅清空缓存并重建迭代器；已加载类无法卸载，JVM 不支持热替换，且 reload() 不触发资源重读或类加载，故修改后需重启应用才生效。
ServiceLoader.reload() 不会重新加载已加载的 SPI 实现类，它只是清空内部缓存、重建迭代器——已加载的类实例不会被卸载或替换，JVM 类加载器也不支持热替换。
为什么 ServiceLoader.reload() 看起来没生效
常见错误现象：ServiceLoader.load(MyService.class) 后调用 reload()，再遍历时仍返回旧实现；修改 JAR 或 classpath 后重启应用才生效。
根本原因在于：ServiceLoader 是懒加载 + 单次缓存机制。它只在第一次调用 iterator() 时扫描并加载类，后续调用 reload() 只是丢弃已构建的 Iterator，下次遍历仍走同一 ClassLoader 的同一查找路径，不会重新触发类加载。
-
reload()不触发类卸载（JVM 不允许） - 不重新读取
META-INF/services/xxx文件内容（除非底层ClassLoader.getResources()返回新结果） - 如果 classpath 没变、资源 URL 没变，
reload()等价于“啥也没干”
真正能动态切换 SPI 实现的可行路径
使用场景：插件化、模块热更新、测试时快速切换 mock 实现。
立即学习“Java免费学习笔记（深入）”；
必须绕过默认 ServiceLoader 的缓存和懒加载限制：
- 每次需要新实例时，显式创建新
ServiceLoader实例：ServiceLoader.load(MyService.class, customClassLoader) - 配合自定义
ClassLoader（如URLClassLoader），指向新 JAR 或目录，确保getResources()返回更新后的服务文件 - 避免复用同一个
ServiceLoader对象 —— 它的缓存是实例级的，不可清除 - 注意：SPI 接口本身不能被重载，否则类型不匹配；建议接口定义在共享 classpath，实现在隔离 classpath
ServiceLoader 在不同 JDK 版本下的行为差异
参数差异与兼容性影响：
- JDK 9+ 支持模块系统，若服务提供者在模块中，需在
module-info.java中声明uses MyService，否则ServiceLoader找不到 - JDK 11 开始，
ServiceLoader.loadInstalled()仅查找java.base等系统模块中的服务，与reload()无关但常被混淆 - 所有版本中，
reload()都不刷新ClassLoader的资源缓存 —— 这是底层URLClassLoader的行为，不是ServiceLoader的 bug
容易被忽略的关键点
性能与可靠性陷阱：
- 频繁新建
ServiceLoader实例不耗性能，但频繁创建ClassLoader会导致元空间泄漏（尤其 Tomcat 等容器中未 close） -
META-INF/services/xxx文件必须 UTF-8 编码且无 BOM，Windows 记事本保存易出错，导致NoClassDefFoundError或静默跳过 - 多个 JAR 提供同一服务时，
ServiceLoader按ClassLoader.getResources()返回顺序加载，顺序不可控 —— 别依赖“后加载覆盖前加载”
动态 SPI 的核心不在 reload()，而在可控的类加载边界和资源发现时机。想让它动起来，得亲手管好 ClassLoader 和资源路径，而不是指望一个清空迭代器的方法。
