Java 基础
本文讨论 Java 语言、对象契约、泛型、注解、异常、反射与 SPI。以 JDK 8 的基本语义为起点，明确标注 JDK 17、21、25 的差异；示例未标注版本时采用 JDK 8 可用的写法。集合实现见 Java 集合，语言特性的正式版本见 Java 新版本。
对象模型与语言语义
易 · 封装、继承、多态解决什么问题？
封装的目标是维护对象的不变量，而不是机械地为所有字段生成 getter/setter。例如账户通过 deposit、withdraw 控制余额变化，比公开 setBalance 更能表达约束。可变集合即使是 private final，若直接返回其引用，外部仍可绕过约束修改内容。
继承表达可替换的类型关系。子类型必须遵守父类型对输入、输出和副作用的约定，不能只是为了复用几行代码继承；只需要复用实现时优先考虑组合。子类不直接访问父类的 private 成员，但这些字段仍然属于对象的父类状态，可由父类方法操作。
运行时多态体现在实例方法的动态分派：编译期检查引用类型是否有可调用的方法，运行期按实际对象类型选择覆盖后的实现。接口实现同样支持多态，并不要求调用方显式写一次向上转型。
interface Instrument {
String play();
}
final class Wind implements Instrument {
@Override
public String play() {
return "wind";
}
}
Instrument instrument = new Wind();
String sound = instrument.play();追问：重载与重写有什么区别？重载在编译期根据方法名、参数类型等选择签名，返回类型不同本身不能形成重载；重写针对继承的实例方法，允许协变返回类型，不能缩小访问权限或扩大受检异常范围。字段访问、静态方法隐藏不具有实例方法的动态分派语义，private 方法也不被子类重写。
中 · 接口与抽象类如何选择？
| 维度 | 接口 | 抽象类 |
|---|---|---|
| 主要用途 | 描述能力、协议与可替换实现 | 共享状态、构造约束和部分实现 |
| 类型关系 | 一个类可以实现多个接口 | 一个类只能直接继承一个类 |
| 实例状态与构造器 | 没有实例字段和构造器；字段隐含 public static final | 可有实例字段、构造器和初始化逻辑 |
| 方法 | 抽象方法、JDK 8 起的默认/静态方法、JDK 9 起的私有辅助方法 | 抽象和具体方法，可采用不同访问权限 |
| 演进风险 | 默认方法有助于接口演进，但可能引入冲突 | 父类实现变更可能影响所有子类 |
接口静态方法通过接口名调用，不由实现类继承。默认方法冲突遵循“类方法优先、更具体的接口优先”；两个互不相关的接口提供相同签名时，实现类需要显式覆盖，可通过 InterfaceName.super.method() 选择默认实现。
追问：默认方法是否保证所有接口变更都兼容？不保证。新增抽象方法、默认方法冲突、泛型擦除后的签名冲突，以及行为契约变化，仍可能破坏源码、二进制或行为兼容性。
中 · this()、super() 与对象初始化有什么边界？
this(...) 委托同类的另一个构造器，super(...) 调用直接父类的构造器。构造器不是普通实例方法，不被继承，也不能在普通方法或静态环境中调用。构造链最终到达父类构造器，不能递归委托；同一个构造器不能同时显式调用 this(...) 与 super(...)。
JDK 8、17、21 中，显式构造器调用必须位于构造器体第一条语句；未写时通常隐式插入 super()，因此父类必须有可访问的无参构造器。JDK 25 的正式特性“灵活的构造器体”允许在显式调用前做安全的参数校验、局部计算及受限制的本类字段赋值，但不能任意读取或暴露尚未完成构造的对象，不能套用为“构造器中任何位置都能使用 this”。
在传统构造流程中，父类构造完成后，按文本顺序执行本类实例字段初始化器和初始化块，再执行本类构造器余下部分。不要在构造器中调用可被覆盖的方法：动态分派可能进入子类，而此时子类字段仍是默认值。也不要在构造期间向外部注册 this，否则会发布部分初始化的对象。
中 · a = a + b 与 a += b 为什么不总等价？
byte、short、char 参与普通整数算术时通常先提升为 int。复合赋值隐含向左侧类型的窄化转换，并且只求值左侧表达式一次。
byte a = 127;
byte b = 1;
// a = a + b; // 编译错误：int 不能隐式转为 byte
a += b; // 相当于窄化转换，结果为 -128
int[] values = {10, 20};
int i = 0;
values[i++] += 5; // i 只递增一次窄化并不检查整数溢出。需要溢出检查时可用 Math.addExact 等方法，不能把复合赋值的“可以编译”当作数值安全。
易 · 浮点计算、移位与 switch 有哪些易错点？
二进制浮点数无法精确表示许多十进制小数，所以 3 * 0.1 == 0.3 为 false。金融十进制运算通常选择 BigDecimal，从字符串或 BigDecimal.valueOf 构建，并明确舍入规则；new BigDecimal(0.1) 会保留该 double 的近似值。BigDecimal.equals 同时比较数值与 scale，compareTo 则可认为 1.0 与 1.00 数值相等。
| 运算 | 含义 | 边界 |
|---|---|---|
x << n | 左移、低位补零 | 高位丢弃，整数溢出不报错 |
x >> n | 算术右移、高位补符号位 | -3 >> 1 为 -2，而 -3 / 2 为 -1 |
x >>> n | 逻辑右移、高位补零 | 负数右移后可得到大的正数 |
int 移位距离只取低 5 位，long 只取低 6 位，所以 1 << 32 等于 1。小整数类型移位前会提升为 int。
switch 从 Java 7 起支持 String，判断语义基于字符串相等，不是仅比较哈希值；编译器可能用哈希分派后再调用 equals 处理碰撞。JDK 8 的字符串 switch 遇到 null 会抛出 NullPointerException。JDK 21 的模式匹配 switch 可以显式写 case null，但普通 default 不自动接管 null。
相等性、字符串与不可变性
中 · ==、equals、hashCode 必须满足什么契约？
引用类型的 == 比较是否指向同一个对象；Object.equals 的默认实现也是身份相等，业务值对象可以覆盖它。基本类型的 == 比较值，但需要留意浮点 NaN、带符号零与数值提升。不要依赖包装类型缓存或字符串驻留，让引用相等偶然充当值相等。
equals 必须满足自反、对称、传递、一致，并对 null 返回 false。只要参与相等性比较的状态未改变，同一执行期间的 hashCode 应保持一致；相等对象必须返回相同哈希值，不相等对象允许碰撞。哈希值既不是唯一标识，也不要求跨进程、跨运行保持一致。
import java.util.Objects;
final class UserKey {
private final long tenantId;
private final String username;
UserKey(long tenantId, String username) {
this.tenantId = tenantId;
this.username = Objects.requireNonNull(username, "username");
}
@Override
public boolean equals(Object other) {
if (this == other) return true;
if (!(other instanceof UserKey)) return false;
UserKey that = (UserKey) other;
return tenantId == that.tenantId && username.equals(that.username);
}
@Override
public int hashCode() {
return 31 * Long.hashCode(tenantId) + username.hashCode();
}
}这里把类设为 final，避免子类添加相等性状态后破坏对称或传递性。继承体系中不能机械混用 getClass() 与 instanceof，应先决定不同运行时类型能否在领域上相等。
追问：为什么哈希容器的键不宜可变？入表时按旧哈希定位桶，修改相等性字段后按新哈希查找，可能找不到原条目；即使碰巧仍在同一桶，也可能破坏去重语义。应采用不可变键，或先移除、修改后重新加入。
中 · String、StringBuilder、StringBuffer 如何选择？
| 类型 | 可变性 | 并发语义 | 适用场景 |
|---|---|---|---|
String | 内容不可变 | 内容可安全共享，引用更新仍需正确同步 | 文本值、键、协议字段 |
StringBuilder | 可变 | 不提供同步保证 | 单线程或线程封闭的字符串构建 |
StringBuffer | 可变 | 主要操作有同步，但多次调用的组合不自动原子 | 确实需要共享且能正确协调访问的旧接口 |
String 不可变不只是因为类被 final 修饰，还依靠内部存储的封装、不暴露可写数组、操作不原地修改内容。不能从 final 推导任意类线程安全。JDK 8 中字符串内部主要使用 char[]；JDK 9 的 Compact Strings 改用带编码标记的 byte[]，这是实现细节，不改变 Java 的 UTF-16 字符串抽象。
循环累加大量片段时可用 StringBuilder，有合理估计时预设容量。不要把所有 + 一律替换为 builder：编译期常量可以折叠，现代 JDK 的字符串拼接也有专门实现；对局部简单表达式优先可读性。length() 统计 UTF-16 代码单元，补充字符可能占两个 char，按用户可见字符截断还需要考虑字素边界。
中 · final、finally、finalize 为什么不能混淆？
final 修饰变量表示只能赋值一次，引用指向的对象仍可能可变；修饰方法禁止覆盖，修饰类禁止继承。正确构造且没有 this 逃逸的对象，其 final 字段还具有 Java 内存模型中的初始化安全语义，但这不等于所有非 final 状态也能无同步共享。
finally 是控制流结构：正常返回和异常传播通常都会执行它，但进程被终止、Runtime.halt、JVM 崩溃或代码一直无法离开 try 等情形不保证执行。不要在 finally 中 return 或抛新异常，否则可能覆盖原返回值或原异常。
finalize() 是历史终结机制，不保证及时执行，甚至不保证一定执行，不能用于关闭文件或数据库连接。它自 JDK 9 起被弃用，JDK 18 起被标记为将移除。资源优先用 AutoCloseable 与 try-with-resources；JDK 9 起的 Cleaner 只适合作为非确定性的兜底，不代替显式关闭。
泛型与类型系统
中 · 泛型提供什么能力，为什么不能用于任意数值相加？
泛型通过类型参数在复用算法的同时保留静态类型约束，把许多强制转换错误提前为编译错误。原始类型 List 会绕过部分检查；List<String> 约束正常 Java 代码只能加入字符串，但反射、原始类型混用等仍可能制造堆污染。
interface Value<T> {
T get();
}
final class Box<T> implements Value<T> {
private final T value;
Box(T value) {
this.value = value;
}
@Override
public T get() {
return value;
}
}
final class Pair<K, V> {
final K key;
final V value;
Pair(K key, V value) {
this.key = key;
this.value = value;
}
}类型参数不能使用基本类型，使用 Box<Integer> 而不是 Box<int>。<T extends Number> 只允许调用 Number 暴露的方法，并未赋予 T 加法运算符；把所有数值先转成 double 会丢失大整数或高精度十进制的语义。数值算法应选择明确类型，或把运算作为函数传入。
中 · 泛型方法、上界、下界与 PECS 如何使用？
泛型方法把类型变量声明在返回类型之前，可出现在非泛型类中，由实参推断或显式指定类型。它不要求传入 Class<T>，也不需要为了换类型重新创建宿主对象。
import java.util.List;
final class Copies {
static <T> T identity(T value) {
return value;
}
static <T> void appendAll(List<? super T> target,
List<? extends T> source) {
for (T value : source) {
target.add(value);
}
}
}泛型不协变：List<Integer> 不是 List<Number> 的子类型，否则可经后者写入 Double。List<? extends Number> 表示具体元素类型未知但一定是 Number 的某种子类型，可读成 Number，不能安全加入某个非 null 数值；List<? super Integer> 可加入 Integer，读取通常只能按 Object 使用。
PECS 是“生产者使用 extends，消费者使用 super”，以参数相对于方法的角色为准，不是“extends 集合完全只读”：仍可能执行 clear、迭代删除等操作，前提是集合支持这些操作。通配符不能作为类型参数声明的下界，<T super Integer> 非法；交叉上界可以写成 <T extends Number & Comparable<T>>，类上界必须放第一位。
追问：同一个容器既读又写还要保留精确类型怎么办？通常使用命名类型变量 T 建立参数和返回值之间的联系，或写通配符捕获辅助方法，而不是强制转换。
难 · 类型擦除到底擦掉了什么，什么仍然保留？
Java 泛型采用擦除实现。编译器先做类型检查，再把类型变量擦除为其最左上界，无显式上界时是 Object；在必要处插入类型转换，并可能生成桥接方法维护重写语义。因此 List<String> 与 List<Integer> 通常共享同一个运行时 Class。
“擦除后所有类型信息都消失”不准确：类、字段、方法声明的泛型签名可保存在 class 文件的 Signature 属性，供反射读取；但普通对象不会因此携带所有实际类型实参。Class.forName 返回 Class<?>，不会因为字符串是某个类名就静态变成 Class<User>。
常见约束及原因：
| 约束 | 原因与处理 |
|---|---|
不能 new T()、T.class | 运行时缺少具体 T；显式传入 Supplier<T> 或适当的 Class<T> |
不能 new List<String>[10] | 数组运行时检查元素类型，参数化类型一般不可具体化；优先集合嵌套 |
不能 instanceof List<String> | 运行期无法检查元素参数；可检查 List<?>，再按业务验证元素 |
不能按 List<String> / List<Integer> 重载 | 擦除后签名相同 |
| 泛型可变参数可能产生堆污染 | 数组与泛型组合有风险；只在确认实现安全时使用 @SafeVarargs |
桥接方法例子：Value<String> 的实现提供 String get()，编译器可能额外生成返回 Object 的桥接方法转调它。框架反射枚举方法时可通过 isBridge()、isSynthetic() 判断，避免重复处理。
注解与元数据
易 · 注解何时生效，元注解控制什么？
注解本身是元数据，不会自动执行校验、事务或依赖注入。编译器、注解处理器、字节码工具或运行时框架解释元数据后才产生行为。
| 元注解 | 控制内容 | 常见误区 |
|---|---|---|
@Retention | SOURCE、CLASS、RUNTIME 的保留阶段，默认 CLASS | 能写在代码里不代表运行期能反射读取 |
@Target | 类型、字段、方法、参数、类型使用等合法位置 | TYPE 与 JDK 8 起的 TYPE_USE 不同 |
@Documented | 是否进入生成的 API 文档 | 不决定运行期可见性 |
@Inherited | 类注解通过父类继承查询的语义 | 不会自动继承接口注解或被覆盖方法上的注解 |
@Repeatable | 声明同一位置可重复使用，指定容器注解 | 读取时通常用 getAnnotationsByType 展开容器 |
@Override 让编译器检查重写关系，@SuppressWarnings 抑制特定编译警告，不能修复类型不安全；@Deprecated 表达 API 的弃用意图。JDK 8 的类型注解允许在类型使用位置附加元数据，但需要工具解释，例如空值分析器。是否进入 class 文件、是否运行期可见仍受 retention 控制，不能说“类型注解不会进入字节码”。
中 · 如何声明可运行期读取的注解？
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@interface Audit {
String action();
}
class OrderActions {
private boolean cancelled;
@Audit(action = "cancel")
public void cancel() {
cancelled = true;
}
public boolean isCancelled() {
return cancelled;
}
}注解元素只允许规定的类型，如基本类型、String、Class、枚举、注解及其一维数组，不支持任意对象或 null 默认值。编译期处理器通常用于生成代码、索引或校验；运行期读取则需考虑扫描范围、代理类、桥接方法和父子类上的声明位置。
追问：为什么直接调用带注解的方法没有事务效果？注解是描述，事务还需要代理、拦截器或字节码增强等执行机制；调用是否经过拦截入口是框架层问题。
异常与资源管理
易 · checked、unchecked、throw、throws 怎样区分？
Throwable 的主要分支是 Error 与 Exception。RuntimeException 及其子类、Error 及其子类属于非受检异常；其余异常类属于受检异常，编译器要求在可达抛出路径上捕获或声明。受检异常不是“编译时发生的异常”，它们同样在运行时抛出。
throw expression 实际抛出一个 Throwable 实例，throws 在方法签名中声明可能向外传播的异常类型。异常是否受检是类型层级规则，不能简单等同于“能不能恢复”。Error 也能被捕获，但通常不应笼统捕获后继续运行，内存耗尽、链接错误等可能已破坏应用前提。
API 设计应让调用者理解恢复责任：参数违约通常用 IllegalArgumentException，可由调用者处理的外部故障可选择受检异常或领域异常；转换异常时保留 cause，不要只复制 getMessage()。捕获应从具体到一般，避免“捕获 Exception 后返回成功”。
中 · try-with-resources 如何关闭资源并保留原始异常？
Java 7 起，try-with-resources 自动关闭实现 AutoCloseable 的资源。多个资源按声明的逆序关闭；后一个资源初始化失败时，之前成功创建的资源也会关闭。JDK 9 起可直接引用已有的 final 或 effectively final 资源变量。
import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
final class TextFiles {
static String firstLine(Path path) throws IOException {
try (BufferedReader reader = Files.newBufferedReader(
path, StandardCharsets.UTF_8)) {
return reader.readLine(); // 空文件返回 null，这是此 API 的约定。
}
}
}若主体与 close() 都抛异常，主体异常继续传播，关闭异常放入其 getSuppressed()；若主体成功而关闭失败，则传播关闭异常。手写 finally 很容易让关闭异常覆盖真正的业务故障。数据库事务提交、回滚不是关闭资源语法自动完成的业务策略，必须另外定义。
追问：捕获 InterruptedException 后怎么办？能向上声明时继续抛出；无法抛出且决定结束当前工作时，通常通过 Thread.currentThread().interrupt() 恢复中断标志，让上层观察取消信号，不能当普通错误吞掉后继续循环。
难 · JVM 如何查找异常处理器，为什么异常不宜做普通分支？
方法的 Code 属性可携带异常表，每个条目包含受保护的字节码范围 [start_pc, end_pc)、处理器入口 handler_pc 与捕获类型。抛出异常后，JVM 在当前方法中按异常表顺序查找覆盖当前指令且类型匹配的处理器；没有则展开栈帧并在调用方继续查找。最终无人处理时进入线程的未捕获异常处理流程。
Java 编译器通常通过复制控制流等方式实现 finally，并为异常路径安排处理器；具体字节码受编译器和版本影响，不应把一份 javap 输出当成唯一模板。
构造常规异常通常会采集栈轨迹，频繁抛出还带来栈展开与控制流成本。用正常返回值表达正常业务分支，用异常表达不满足方法正常完成前提的情况。排障时应结合 cause 链、suppressed 异常、最早业务栈帧和相关请求上下文，避免每层重复记录同一堆栈或只看最外层包装异常。
反射与模块边界
中 · Class、Constructor、Field、Method 如何使用？
反射允许在运行期检查类型信息、创建对象和调用成员，但始终受语言访问规则与模块边界约束。Type.class、obj.getClass()、Class.forName(name) 都可获得 Class；Class.forName(String) 通常还会触发类初始化，而类字面量本身不等于执行类初始化。
getMethods() 返回 public 方法（包括继承的方法），getDeclaredMethods() 返回该类自己声明的方法（包括非 public 方法，不含继承的方法）。字段和构造器也有对应区别。不要依赖反射返回成员的枚举顺序。
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
final class ReflectionDemo {
public static class User {
private String name;
public User(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
static String readName() throws ReflectiveOperationException {
Constructor<User> ctor = User.class.getConstructor(String.class);
User user = ctor.newInstance("Ada");
Field field = User.class.getDeclaredField("name");
field.setAccessible(true); // 本例同模块；跨模块并不保证成功。
field.set(user, "Grace");
Method method = User.class.getMethod("getName");
return (String) method.invoke(user);
}
}新代码使用 getDeclaredConstructor(...).newInstance(...) 等构造器 API，避免已弃用的 Class.newInstance()。Method.invoke 的目标方法抛出异常时通常包装为 InvocationTargetException，需要查看 getCause()；方法不可访问、参数错误、找不到成员等属于不同失败原因，不能统一解释成“类没加载”。反射也不应被用于破坏对象的不可变约定或任意修改 final 字段。
难 · 为什么 JDK 8 能反射，迁移 JDK 17 却报错？
Java 9 引入模块系统，JDK 17 的 JEP 403 强封装 JDK 内部 API。setAccessible(true) 只是请求抑制部分访问检查，不是绕过一切权限的后门。跨命名模块对非公开成员进行深反射，通常需要目标包向调用模块 opens；不满足时可能抛 InaccessibleObjectException。JDK 9 起的 trySetAccessible() 可以在无法开放时返回 false。
exports 面向正常编译和 public API 访问，opens 面向深反射。短期兼容可按具体错误设置 --add-opens java.base/java.lang=ALL-UNNAMED 等精确开放选项，但应先升级依赖、迁移到受支持 API，不能把所有包全部开放当作永久方案。--add-exports 与 --add-opens 的作用也不同。
排查顺序：确认报错的目标模块、包与调用方；检查库的 JDK 支持矩阵；确认应用在 classpath 还是 module path；最后才决定是否需要受控开放。反射性能也不能只用“比直接调用慢多少倍”概括，缓存元数据、调用形态、JIT 与 JDK 实现都会影响结果。
中 · getName、getCanonicalName、getSimpleName 有什么区别？
| 类型例子 | getName() | getCanonicalName() | getSimpleName() |
|---|---|---|---|
java.lang.String | java.lang.String | java.lang.String | String |
String[] | [Ljava.lang.String; | java.lang.String[] | String[] |
int[] | [I | int[] | int[] |
成员类 Outer.Inner | 使用 $，如 pkg.Outer$Inner | 使用 .，如 pkg.Outer.Inner | Inner |
局部类、匿名类可能没有 canonical name，返回 null；匿名类 simple name 通常为空。不要把日志展示名称直接用作稳定序列化标识，Class.forName 使用的名称规则也不能一概用 canonical name 替换。
SPI 与可扩展组件
易 · SPI 与普通 API 的调用方向有什么区别？
API 通常是应用调用组件提供的能力；SPI 是组件定义扩展契约，由第三方实现后供组件发现和调用。例如 JDBC 定义 java.sql.Driver，数据库厂商提供驱动。Java 的标准服务发现工具是 ServiceLoader，它负责发现与实例化，不自动提供依赖注入、优先级选择、生命周期关闭或热部署。
classpath 模式中，提供者 JAR 包含 META-INF/services/<服务接口二进制全限定名> 的 UTF-8 文本文件，每行一个实现类全限定名，支持空行与 # 注释。提供者需要可访问、符合服务类型并有 public 无参构造器。构建合并 JAR 时要保留并合并服务配置，直接覆盖文件可能让提供者消失。
中 · 如何实现一个可实际发现的服务？
以下代码分别放入标注的文件；服务实现返回确定结果，避免只输出日志再返回 null 的无效示例。
// com/example/spi/TextTransform.java
package com.example.spi;
public interface TextTransform {
String name();
String apply(String input);
}// com/example/provider/UppercaseTransform.java
package com.example.provider;
import com.example.spi.TextTransform;
import java.util.Locale;
import java.util.Objects;
public final class UppercaseTransform implements TextTransform {
public UppercaseTransform() {}
public String name() {
return "uppercase";
}
public String apply(String input) {
return Objects.requireNonNull(input, "input").toUpperCase(Locale.ROOT);
}
}提供者资源文件 META-INF/services/com.example.spi.TextTransform 内容为：
com.example.provider.UppercaseTransform消费者通过接口调用，不依赖具体实现：
import com.example.spi.TextTransform;
import java.util.ServiceLoader;
final class TransformClient {
static String uppercase(String input) {
for (TextTransform transform : ServiceLoader.load(TextTransform.class)) {
if ("uppercase".equals(transform.name())) {
return transform.apply(input);
}
}
throw new IllegalStateException("未发现 uppercase 服务提供者");
}
}示例以服务名选择实现；实际若允许重复名称，应显式定义冲突策略，不把发现顺序当业务优先级。ServiceLoader 通常延迟发现、实例化并缓存提供者，迭代时也可能抛 ServiceConfigurationError；reload() 清除其缓存，不等于重新加载已定义的类，实例本身也不保证多线程安全。
难 · 模块化 SPI、类加载器与 JDBC 自动发现如何排障？
JDK 9 起，命名模块消费者通过 uses com.example.spi.TextTransform 声明使用服务，提供者模块通过 provides ... with ... 注册实现；服务所在模块需要导出服务接口包。消费者只需依赖服务契约模块，不应为了发现而直接依赖每个提供者模块。显式命名模块还支持合规的 public static 无参 provider() 工厂方法；classpath 和自动模块提供者不能据此绕过无参构造器要求。
默认 ServiceLoader.load(Service.class) 使用线程上下文类加载器，这有助于容器中上层 API 发现应用提供者，但可能受到线程、插件隔离和模块层影响。需要时显式传入类加载器或模块层，确保服务接口与实现看到的是相容的类型身份。
JDBC 4 起合规驱动可自动发现，通常无需 Class.forName 手动注册；前提是驱动在正确的运行期路径中且服务配置可见。No suitable driver 还可能来自 JDBC URL 不匹配、驱动版本不支持或类加载隔离。应检查打包资源、运行期依赖、上下文类加载器和 URL，而不是直接换成历史驱动类名。连接需要通过 try-with-resources 管理，并由应用配置真实 URL 与凭据。