InstantiationException 是受检异常，根本原因在于类结构不支持无参实例化：抽象类、接口、无public无参构造或构造器不可访问均会触发，需通过getCause()定位真实异常并校验类类型。
InstantiationException 是 Java 中一个典型的受检异常，但它真正的问题往往不是“要不要捕获”，而是“为什么会在运行时突然炸开”。它不反映代码写错了语法，而是在反射创建对象时，JVM 明确拒绝了实例化请求——背后通常是类结构本身就不支持直接构造。
别只 catch，先看 cause
这个异常几乎总是包装异常。直接捕获 InstantiationException 并打印堆栈，大概率看不到真实原因。关键在 getCause()：
- 如果 cause 是 NoSuchMethodException：说明 JVM 找不到可访问的 public 无参构造器（注意：只要写了带参构造，编译器就不会自动生成默认无参构造）
- 如果 cause 是 IllegalAccessException：构造器存在，但权限不够（比如是 private），需要 setAccessible(true)
- 如果 cause 是 InvocationTargetException：构造函数执行过程中抛出了业务异常（如空指针、IO失败），得继续调 getTargetException() 挖到底
抽象类和接口是硬性禁区
JVM 字节码验证阶段就禁止实例化 abstract 类或 interface，反射也绕不过去。这不是权限问题，是语义不允许：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 报错消息常为 "Can't instantiate interface xxx" 或 "xxx is abstract; cannot be instantiated"
- 常见于配置驱动场景：Spring 的 @Bean 返回 new AbstractService()、MyBatis 的 resultType 写了接口、Jackson 反序列化指定了抽象基类
- 解决方式不是 try-catch，而是提前校验：clazz.isInterface()、Modifier.isAbstract(clazz.getModifiers())、clazz.isEnum()，发现就立刻拒绝或切换为具体实现类
用对 API，绕过已废弃陷阱
Class.newInstance() 在 Java 9+ 已废弃，它隐式依赖 public 无参构造，且无法处理受检异常或私有构造器：
立即学习“Java免费学习笔记（深入）”；
- 改用 getDeclaredConstructor().newInstance()，能显式控制参数类型和访问权限
- 遇到 private 构造器？先调 setAccessible(true)，再 newInstance()
- 如果类有多个构造器，务必用 getDeclaredConstructor(Class>...) 精确匹配，避免参数类型不匹配导致 NoSuchMethodException
无参构造不是万能解药
加个 public 无参构造器不一定能解决问题：
- 内部类（非 static）必须传入外部类实例，否则 newInstance() 会失败
- 构造函数里如果 new 了另一个缺失配置的 bean，照样抛 InvocationTargetException
- 模块化环境下（Java 9+），即使构造器 public，若所在模块未导出包，也会触发 IllegalAccessException
