assemblyloadcontext通过创建独立的程序集加载环境解决了dll hell和动态卸载难题，它允许每个插件在隔离的上下文中加载所需版本的依赖，避免冲突，并支持在运行时卸载整个上下文以释放资源；其核心机制是通过自定义assemblyloadcontext子类并重写load方法实现“子级优先”的解析策略，确保插件优先使用自身依赖，同时可通过assemblydependencyresolver定位依赖路径；为实现安全卸载，必须消除所有对上下文内对象的强引用，包括取消事件订阅、清理静态变量、停止线程与任务，并可通过实现iplugincleanup接口或监听unloading事件来执行清理操作，最终在无引用残留的情况下调用unload()方法完成卸载，从而实现高效、可扩展且资源可控的插件化架构。
`.NET的AssemblyLoadContext类提供了一种强大的机制，用于在单个应用程序域内隔离程序集的加载。简单来说，它就像是为你的程序集创建了一个个独立的“小房间”，每个房间都有自己的规则和环境，从而有效避免了不同组件之间因依赖版本冲突而引发的“DLL Hell”问题，并允许动态地卸载不再需要的程序集，释放资源。
在.NET Core/.NET 5+的世界里，
AssemblyLoadContext
是处理程序集加载的核心。当你启动一个应用程序时，所有默认的程序集都会被加载到
AssemblyLoadContext.Default
这个默认上下文里。但真正的魔力在于，你可以创建自己的自定义上下文。
想象一下，你正在构建一个插件系统。每个插件可能依赖不同版本的同一个库，比如插件A需要
Newtonsoft.Json
的12.0版本，而插件B却需要13.0版本。如果都加载到默认上下文，那肯定会出问题。这时候，你就可以为每个插件创建一个独立的
AssemblyLoadContext
实例。
当你调用
new CustomAssemblyLoadContext().LoadFromAssemblyPath("path/to/plugin.dll")
时，这个插件及其所有依赖就会被加载到这个自定义的上下文里。这个上下文会有一套自己的解析规则：它会先尝试在自己的加载路径中找到依赖，如果找不到，它会“问”它的父上下文（通常是
Default
上下文）是否已经加载了对应的程序集。这种“父级优先”的委托模型是默认行为，它能确保共享的系统库或框架库只被加载一次，节省内存。但你也可以通过重写
Load
方法来改变这种行为，比如实现一个“子级优先”的策略，让插件优先加载自己携带的依赖，只有当它没有时才考虑父级。
最令人兴奋的是它的卸载能力。当一个插件不再需要时，你可以通过释放对该
AssemblyLoadContext
实例的所有引用，并调用它的
Unload()
方法（如果它是一个可收集的上下文），系统就会尝试卸载这个上下文以及其中加载的所有程序集。这对于长时间运行的服务、动态更新的应用程序或者需要即时释放资源的场景来说，简直是福音。当然，这并不是简单的“一键清除”，背后有很多细节需要注意，比如确保没有对该上下文内部对象的强引用，否则卸载会失败。
为什么我们需要AssemblyLoadContext？它解决了哪些实际问题？
说实话，刚接触这个类的时候，我个人觉得有点复杂，不就是加载个DLL嘛，以前不是也能加载吗？但深入了解后才发现，它解决了太多以前让人头疼的问题。最核心的，无疑是“DLL Hell”这个老生常谈的话题。设想一下，你的主程序依赖了某个库的A版本，然后你又想集成一个第三方组件，结果这个组件依赖了同一个库的B版本。在没有
AssemblyLoadContext
之前，这几乎是个死局，你可能需要妥协，或者想方设法让两者兼容，那过程简直是噩梦。
AssemblyLoadContext
的出现，就像给每个组件划定了势力范围。每个插件或模块都可以在自己的“沙盒”里运行，使用它自己需要的特定版本依赖，而不会干扰到其他模块或主程序。这对于构建可扩展的应用程序，尤其是那些支持插件、模块化架构的系统，简直是基石。
除此之外，它还带来了动态卸载的能力。以前，一旦程序集加载到内存，除非整个进程退出，否则它会一直占用资源。这对于需要热更新、频繁加载/卸载组件的场景（比如一些CAD软件的插件、游戏MOD加载器，或者云服务中动态部署的小型应用）来说，是极大的限制。
AssemblyLoadContext
让这种动态生命周期管理成为可能，你可以在运行时加载新功能，也能在不再需要时干净地移除它们，释放内存和其他资源，这对于追求高可用和资源效率的系统至关重要。
如何自定义AssemblyLoadContext的行为？有哪些常见的加载策略？
自定义
AssemblyLoadContext
的行为，通常意味着你要重写它的
Load
方法，这是你介入程序集解析过程的关键点。当你创建一个
AssemblyLoadContext
的子类时，你可以根据自己的逻辑来决定如何找到并加载一个程序集。
最常见的自定义场景就是改变默认的“父级优先”委托模型。默认情况下，当一个
AssemblyLoadContext
需要加载一个程序集时，它会先检查其父上下文（通常是
Default
）是否已经加载了该程序集。如果父上下文已经加载，它就会直接使用父上下文的版本。这种策略对于共享框架库非常有效，避免了重复加载。
然而，在插件架构中，你可能需要“子级优先”策略。这意味着你的自定义上下文会优先尝试在自己的加载路径中找到并加载程序集，只有当它自己找不到时，才会委托给父上下文。这对于确保插件使用其自带的特定版本依赖非常有用，即使父上下文有不同版本，插件也能保持其独立性。实现这种策略，你需要在重写的
Load
方法中，先尝试通过
LoadFromAssemblyPath
或其他
LoadFrom*
方法在自己的指定路径中查找，如果失败，再调用基类的
Load
方法（即
base.Load(assemblyName)
）来触发父级委托。
public class PluginLoadContext : AssemblyLoadContext{ private readonly string _pluginPath; private readonly AssemblyDependencyResolver _resolver; public PluginLoadContext(string pluginPath) : base(isCollectible: true) { _pluginPath = pluginPath; _resolver = new AssemblyDependencyResolver(pluginPath); } protected override Assembly Load(AssemblyName assemblyName) { // 尝试在插件的依赖路径中解析 string assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName); if (assemblyPath != null) { return LoadFromAssemblyPath(assemblyPath); } // 如果插件路径中没有，再尝试委托给默认上下文（父级） // 这样可以共享框架程序集，避免重复加载 return null; // 返回null表示让基类或默认上下文处理 } protected override IntPtr LoadUnmanagedDll(string unmanagedDllName) { // 同样，处理非托管DLL的加载 string libraryPath = _resolver.ResolveUnmanagedDllToPath(unmanagedDllName); if (libraryPath != null) { return LoadUnmanagedDllFromPath(libraryPath); } return IntPtr.Zero; // 返回IntPtr.Zero表示让基类或默认上下文处理 }}// 使用示例// string pluginAssemblyPath = "path/to/your/Plugin.dll";// var context = new PluginLoadContext(pluginAssemblyPath);// Assembly pluginAssembly = context.LoadFromAssemblyPath(pluginAssemblyPath);// // ... 使用插件中的类型// context.Unload(); // 当不再需要时卸载
除了这种显式的父子委托，你还可以实现更复杂的逻辑，比如从网络位置加载、从数据库加载二进制数据，或者根据某些配置规则动态选择加载路径。关键在于，
Load
方法是你的“拦截器”，它给了你完全的控制权。
使用AssemblyLoadContext时会遇到哪些挑战？如何确保程序集安全卸载？
使用
AssemblyLoadContext
虽然强大，但它也不是万能药，尤其是在卸载方面，有一些细微之处需要特别留意。我个人在实践中就遇到过不少“卸载失败”的情况，调试起来确实需要耐心。
最大的挑战之一是类型共享问题。即使两个
AssemblyLoadContext
加载了同一个程序集（比如
Newtonsoft.Json
），如果它们是从不同的上下文加载的，那么它们的类型在CLR看来是完全不同的。这意味着你不能直接将一个上下文加载的
JObject
实例赋值给另一个上下文期望的
JObject
类型变量。这会导致
InvalidCastException
。解决办法通常是定义一个共享的接口程序集，这个接口程序集被所有上下文（包括主程序和插件）引用，并且它只包含接口定义，不包含任何实现。这样，主程序和插件之间就可以通过接口进行通信，避免了具体的类型冲突。
另一个让人头疼的问题是确保完全卸载。当你调用
Unload()
方法时，CLR会尝试卸载该上下文及其加载的所有程序集。但如果存在任何对该上下文内部对象的强引用，卸载就会失败。这些强引用可能来自：
静态变量： 你的主程序中可能有一些静态变量引用了插件中的类型或对象。事件订阅： 插件中的对象订阅了主程序中的事件，或者反之。事件订阅本质上就是一种强引用。线程： 插件启动了新的线程，而这些线程仍在运行并持有对插件内部对象的引用。定时器/后台任务： 类似的，如果插件启动了定时器或后台任务，它们可能持有引用。非托管资源： 插件加载的非托管DLL或COM对象，如果未正确释放，也会阻止卸载。
为了确保安全卸载，你需要采取以下策略：
断开所有引用： 这是最关键的一步。在调用
Unload()
之前，必须确保主程序中没有对插件上下文内部任何对象的强引用。这意味着要取消所有事件订阅、清空静态变量、停止所有插件启动的线程和任务。使用弱引用： 如果主程序确实需要临时持有插件中的对象，可以考虑使用
WeakReference
。这样，即使主程序持有引用，垃圾回收器也能够在必要时回收对象，从而允许上下文被卸载。实现清理接口： 为你的插件定义一个
IDisposable
或自定义的
IPluginCleanup
接口。在插件被卸载前，主程序调用这个接口方法，让插件有机会自行清理内部资源，比如取消事件订阅、关闭文件句柄、停止线程等。监听
Unloading
事件：
AssemblyLoadContext
有一个
Unloading
事件。你可以在插件内部订阅这个事件，并在事件触发时执行最后的清理工作，确保所有资源都被释放，所有引用都被断开。隔离非托管资源： 如果插件使用了非托管DLL，确保它们在卸载前被正确地
FreeLibrary
或等效释放。
AssemblyLoadContext
的
LoadUnmanagedDll
方法可以帮助你控制非托管DLL的加载，但释放的责任通常落在插件自身。
卸载失败不会立即抛出异常，但
Unload()
方法会抛出
InvalidOperationException
，或者在某些情况下，上下文会保持加载状态，直到所有引用都被释放。因此，在开发插件系统时，对卸载场景进行充分的测试是必不可少的。这通常意味着你需要模拟插件的生命周期，包括加载、使用和卸载，并监控内存使用情况，确保没有内存泄漏。
以上就是.NET的AssemblyLoadContext类如何隔离程序集加载？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439737.html
微信扫一扫 
支付宝扫一扫 
![Go语言接口与切片：如何识别和操作[]interface{}](https://cdn.chuangxiangniao.com/www/2025/12/176369856569294-1.jpg?imageMogr2/crop/480x300/gravity/center)
