构造器不是方法，jvm明确区分constructor与method两类成员，调用需用getdeclaredconstructors()而非getdeclaredmethods()，且构造器无返回类型、名须同类名、签名固定为。
构造器不是方法，JVM不把它当Method对象处理
Java里Constructor和Method虽然都属于反射体系，但底层类型完全不同。调用clazz.getDeclaredMethods()永远拿不到构造器，必须用clazz.getDeclaredConstructors()——这不是设计疏漏，是JVM规范明确区分的两类成员。
常见错误现象：想用Method.invoke(null, args)去“调用”构造器，结果抛NoSuchMethodException；或者误以为给构造器加@Override能通过编译（实际会报错）。
- 构造器没有返回类型（连
void都不能写），方法必须声明返回类型 - 构造器名必须与类名完全一致，且大小写敏感；方法名可任意（除关键字外）
- 字节码中构造器的签名固定为
<init></init>，方法则是真实方法名，反编译时一眼可辨
new触发的内存分配时机比方法调用早得多
执行new MyClass()时，JVM先在堆上分配足够存放所有实例字段的内存空间（此时字段值还是默认零值），再把这块内存的引用压栈，最后才跳转到<init></init>执行构造逻辑。而普通方法调用，栈帧是在已有对象引用基础上创建的。
这意味着：如果构造器里提前把this泄露出去（比如注册到静态集合、开新线程、传给回调），其他代码拿到的是一个字段尚未初始化完毕的“半成品”对象——这是典型的this逃逸问题，且无法被final字段的语义保护。
立即学习“Java免费学习笔记（深入）”；
- 构造器中避免调用可被子类重写的方法（
super()之后的第一行就可能触发子类逻辑） - 使用
static factory method替代public constructor，能更好控制对象创建流程 - 像
ArrayList(int)这种带参数构造器，内部直接分配数组，不是等add()时才扩容
构造器链式调用只发生在编译期，不生成额外字节码指令
this(...)或super(...)必须是构造器第一行，且只能出现一次。编译器会把它“内联”进当前构造器的字节码，不会生成类似方法调用的invokespecial跳转——所以你在jstack或字节码里看不到多层构造器调用栈。
容易踩的坑：以为this(1); super();这样写能先后触发两个调用，实际编译直接失败；或者在IDE里打断点发现构造器只停一次，误以为父类构造没执行。
- 无参构造器若没显式写
super()，编译器自动补上，但不会补this() - 如果父类只有带参构造器，子类构造器必须显式调用
super(x)，否则编译报错 - 用Lombok的
@AllArgsConstructor生成构造器时，它按字段顺序传参，和手写super(...)的参数顺序要对得上
反射创建对象时，Constructor.newInstance()和Unsafe.allocateInstance()根本不是一回事
前者会完整走构造器逻辑（包括字段初始化、构造器体执行、final字段写屏障）；后者绕过所有构造流程，只分配内存并返回原始对象引用——字段全是默认值，且后续赋值可能被JIT优化掉。
典型场景：序列化框架（如Kryo）用Unsafe快速创建对象，但必须确保字段能安全重赋值；而Spring BeanFactory默认用Constructor.newInstance()，保证@PostConstruct等生命周期回调生效。
-
Constructor.setAccessible(true)仅绕过访问控制检查，不跳过构造逻辑 -
Unsafe.allocateInstance()创建的对象，final字段不会被正确初始化，反序列化时需额外处理 - JDK 9+ 中
Unsafe受限，推荐用VarHandle或Lookup.findConstructor()替代
构造器的语义边界其实很窄：它只负责让对象从“未定义”变成“可安全使用”。一旦混进业务逻辑、依赖注入、甚至IO操作，就很容易在多线程或继承场景下出问题。
