多态参数传递本身不直接实现热插拔，但它为热插拔提供了关键前提：让宿主系统完全不依赖具体插件类，只通过接口类型接收和调用插件；真正的热插拔能力来自运行时类加载、生命周期管理与资源清理的配合。
多态参数传递本身不直接实现热插拔，但它为热插拔提供了关键前提：让宿主系统完全不依赖具体插件类，只通过接口类型接收和调用插件。真正的热插拔能力来自运行时类加载、生命周期管理与资源清理的配合。
用接口类型作为方法参数，彻底解耦宿主逻辑
宿主代码中所有插件相关操作都应基于接口，而非实现类。比如日志模块不写FileLogger logger = new FileLogger()，而是定义：
-
统一入口方法：如
void registerLogger(LoggerPlugin plugin)，参数是接口，不是任何具体实现 -
执行调度不感知实现细节：调用
plugin.log(Level.INFO, "msg")时，宿主无需知道这是文件写入、HTTP上报还是内存缓存 -
避免类型强转或 instanceof 判断：一旦出现
if (plugin instanceof DbLogger)，就破坏了多态契约，后续新增插件就得改宿主代码
参数设计要支持运行时替换与隔离
多态参数只有在结构稳定、语义清晰的前提下，才能支撑插件动态切换：
-
传不可变对象或 DTO：比如用
LogEntry封装日志内容，而不是传Map或ArrayList——后者容易因实现类修改内部结构导致兼容问题 -
返回值明确成功/失败语义：统一用
Result封装，避免不同插件有的抛异常、有的返回null，宿主无法统一处理 - 不暴露实现细节到参数中：例如不要把线程池、配置对象、Spring Bean 作为参数传入，这些应由插件自己初始化或通过上下文注入
热插拔真正依赖的配套机制
仅靠多态参数传递不能“拔”也不能“插”，必须搭配以下机制：
-
独立 ClassLoader 加载插件：每个插件使用自己的
URLClassLoader，卸载时可回收整个类空间，避免类泄漏 -
显式生命周期方法：插件接口需包含
init(Context ctx)、shutdown()，宿主在卸载前主动调用，释放线程、连接、静态引用等资源 -
上下文注入替代全局访问：插件通过
Context获取日志、配置等能力，而非自己LoggerFactory.getLogger(...)——这样宿主可在插件卸载后安全回收上下文实例 -
注册表 + 引用计数管理：宿主维护插件实例引用，确保无外部持有时才触发
shutdown()和ClassLoader.close()
一个典型热插拔流程中的多态作用点
假设用户上传新版本AlertPlugin-v2.jar：
- 宿主用新
ClassLoader加载它，反射获取AlertPlugin实现类实例 - 将该实例以接口类型（如
NotificationPlugin）传给pluginManager.replace("alert", plugin) - 旧插件被
replace方法调用oldPlugin.shutdown()并从注册表移除 - 后续所有
notify(...)调用自动路由到新实例——因为宿主代码始终只认NotificationPlugin接口，没一行改动
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
