MethodHandles.constant 不生成常量池项，它在运行时通过Java代码构造MethodHandle实例，不写入CONSTANT_MethodHandle_info或CONSTANT_MethodType_info，也不依赖字节码符号引用。
MethodHandles.constant 并不生成常量池项（如 CONSTANT_MethodHandle_info 或 CONSTANT_MethodType_info），它是在运行时通过 Java 代码构造一个 MethodHandle 实例，而非在类文件的常量池中定义符号引用。
为什么不能用 MethodHandles.constant 定义“常量池常量”
Java 类文件的常量池是静态结构，在编译期确定。而 MethodHandles.constant(Class, Object) 是一个标准库方法，其行为是：
- 在 JVM 运行时创建一个封装了指定类型和值的
MethodHandle（底层通常对应ConstantObjectHandle） - 该 handle 不依赖任何字节码符号引用，也不写入 class 文件常量池
- 调用它等价于直接返回一个“恒定值”的句柄，例如
MethodHandles.constant(String.class, "hello")返回一个每次调用都返回"hello"的 handle
真正写入常量池的 MethodHandle 相关项
若要在类文件中出现 MethodHandle 相关常量池条目，需满足以下条件之一：
- 使用
invokedynamic指令，且其 Bootstrap Method 的静态参数（BSM static args）中包含MethodHandle或MethodType—— 此时编译器会自动将它们作为CONSTANT_MethodHandle_info和CONSTANT_MethodType_info写入常量池 - 显式调用如
MethodHandles.lookup().findStatic(...)等反射式查找方法 —— 查找过程可能触发对常量池中CONSTANT_MethodRef等项的解析，但constant()本身不参与此过程
常见误解与替代方案
有人希望用 MethodHandles.constant 实现类似 public static final MethodHandle MH_FOO = ... 的“编译期常量”，但要注意：
- 该赋值仍是运行时初始化（在类初始化阶段执行），不是编译期常量（
static final基本类型或字符串字面量除外） - 无法通过 javap 观察到对应的
MethodHandle常量池项；javap -v 显示的常量池里不会有它 - 若目标是减少运行时开销，可考虑将 handle 缓存为
static final字段，但首次获取仍需执行方法调用
小结
MethodHandles.constant 是一个便捷的运行时工具方法，用于快速构建返回固定值的 MethodHandle，它不操作、不生成、也不依赖类文件常量池。所谓“MethodHandle 常量池”指的是由编译器根据字节码指令（主要是 invokedynamic）自动生成的常量池结构，与该 API 无直接关系。
