instantiationexception 是受检异常，因类无无参构造、为抽象类/接口等导致实例化失败；应避免 class.newinstance()，改用 getdeclaredconstructor() 显式获取并调用构造器。
InstantiationException 是受检异常，但它的抛出根源往往不在“是否检查”，而在于类结构本身不支持无参实例化。
它确实是受检异常
InstantiationException 继承自 Exception（不是 RuntimeException），因此属于受检异常（checked exception）。这意味着编译器会强制要求你处理它——要么用 try-catch 捕获，要么在方法签名中用 throws 声明。这和 NullPointerException、ArrayIndexOutOfBoundsException 等非受检异常有本质区别。
没有无参构造函数是常见触发原因
当通过反射调用 Class.newInstance()（已废弃）或 Constructor.newInstance() 时，若目标类：
- 根本没有定义任何构造函数（此时编译器自动提供 public 无参构造）→ 不会出问题
- 只定义了带参数的构造函数 → 编译器不再生成默认无参构造 →
newInstance()找不到可调用的无参构造 → 抛 InstantiationException - 定义了无参构造，但修饰符是
private→ 反射无法访问 → 同样抛此异常
抽象类和接口也会直接导致该异常
即使有无参构造，以下情况仍会抛 InstantiationException：
- 尝试对
abstract class调用 newInstance() → JVM 明确拒绝实例化 - 对
interface或enum、array class、基本类型（如 int.class）做同样操作 → 同样被禁止
这些限制是语言层面的硬性规则，与构造函数是否存在无关。
现代写法应绕过 newInstance() 的陷阱
避免依赖已废弃的 Class.newInstance()，改用更精确的反射流程：
- 用
getDeclaredConstructor()明确获取指定参数类型的构造器 - 若构造器是 private，先调
setAccessible(true) - 再调
constructor.newInstance(args...)
这样既避开无参构造的隐式依赖，又能清晰控制实例化逻辑，也更容易定位是参数不匹配、权限不足还是类本身不可实例化。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
