全盘负责委托机制核心是“管辖权统一”与“自上而下试探”：某类被某classloader加载后，其字段、参数、返回值等所有依赖类默认均由该加载器加载，以防classcastexception；加载前必须先委托父加载器尝试，直至bootstrap，失败后才自行加载。
全盘负责委派机制，核心就两点：谁加载了这个类，它依赖的所有类——字段类型、方法参数、返回值、异常、内部类引用的类——默认也归它管；而它在动手之前，得先请父加载器试试。
全盘负责：管到底，不甩锅
这不是“只管自己加载的那个类”，而是“一旦你加载了 A 类，A 里用到的所有其他类（比如 A 有个字段是 StringUtils，方法返回 CharSequenceUtils），只要没显式指定别的加载器，就都由你来加载”。目的很实在：避免同一个类名+包名被不同加载器重复加载，导致 ClassCastException 或运行时行为错乱。
- 比如 OrderService 被 AppClassLoader 加载，它引用了 StringUtils，而 StringUtils 又依赖 CharSequenceUtils ——这三个类大概率都会落在同一个加载器手里
- 如果中途被不同加载器插手（比如 StringUtils 被 ExtClassLoader 加了，CharSequenceUtils 却被 AppClassLoader 加），哪怕字节码一模一样，JVM 也认为它们是两个不兼容的类
委派机制：先问长辈，再自己干
委派不是甩手不管，而是有顺序的试探。一个类加载器收到请求后，第一反应不是翻自己的路径，而是把任务往上递：先让父加载器找，父不行再找祖父，直到 Bootstrap；全都找不到，才轮到自己从 classpath 或 jar 包里加载。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Bootstrap 加载器负责 java.lang.* 等核心类，确保不会被应用层替换
- ExtClassLoader 负责 JAVA_HOME/jre/lib/ext 下的扩展包
- AppClassLoader（也就是系统类加载器）负责 -classpath 或 java.class.path 指定的路径
它和双亲委派不是一回事，但必须一起用
双亲委派决定“谁先找”，全盘负责决定“谁来管到底”。两者配合才能既安全又可控：
- 双亲委派防止你写的 String 替掉 JVM 自带的 String
- 全盘负责防止你项目里的 commons-lang3-3.12.jar 被拆开：一部分类由父加载器加载旧版，另一部分由子加载器加载新版，结果调用新 API 时直接报 NoSuchMethodError
- 加载成功后，结果会被缓存；下次再要这个类，直接从缓存取，不再重复查找或解析
冲突本质：全盘负责被悄悄打破了
Jar 包冲突往往不是“找不到类”，而是“找错了版本”，根源就是依赖链被不同加载器截断：
- 项目同时引入 guava-29.0 和 guava-32.1，classpath 顺序靠前的先被 AppClassLoader 加载，后续代码按 32 版本编译，却在 29 版本上运行
- 两个中间件各自打包了同名的 net.sf.json.JSONObject，JVM 认为是一个类，但实际加载的是 A 的实现，B 调用时逻辑出错
这时候删 jar 或加
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
