java基本数据类型常量不参与垃圾回收，因其不占用堆内存、不生成对象引用，仅存在于字节码指令、常量池或栈帧中，gc仅管理堆内对象。
Java中基本数据类型常量（如int、boolean、char等字面量）本身不参与垃圾回收，因为它们不占用堆内存，也不生成对象引用。所谓“生命周期的内存判定”，本质上是理解这些常量在编译期、类加载期和运行期的存储位置与存活逻辑，而非GC直接管理的对象。
常量不进堆，GC不扫描
基本类型字面量（如int x = 42;中的42）在编译后通常被内联到字节码指令中（如bipush、sipush），或作为常量池项（仅限final static修饰的编译期常量）。它们不创建对象，不分配堆空间，因此不在GC可达性分析范围内。JVM的垃圾回收器只管理堆中对象的生命周期，对栈上局部变量值、常量池中的基本类型字面量、方法区中的静态字段原始值，均无回收行为。
区分三类“常量”场景
实际开发中需明确以下情形，避免混淆：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
局部变量中的字面量：如
void f() { int a = 100; }，100直接嵌入字节码，随方法栈帧入栈/出栈，生命周期由栈管理，与GC无关； -
static final基本类型常量：如
public static final int MAX = 999;，编译期确定的常量会被存入类的常量池（ConstantPool），类加载时加载，类卸载时才可能清理（极少发生），仍不归GC管； -
包装类缓存对象（易误认为“基本类型常量”）：如
Integer i = 127;会复用IntegerCache中的对象，该对象在堆中，受GC管理——但这已是对象，不是基本类型常量本身。
真正影响GC的是引用关系，不是原始值
基本类型变量（包括常量赋值）若作为对象字段或数组元素存在，其值只是副本，不影响所依附对象的GC判定。例如：
class Data {int id = 1001; // 1001 是字面量，不占堆
String name = "abc"; // "abc" 是字符串对象，可能进字符串常量池（方法区），受类卸载影响
}
当Data实例被判定为不可达时，整个对象（含id字段的值）一起被回收——但回收的是对象容器，不是id这个int值本身。
验证方式：看字节码和内存布局
可通过工具确认常量归属：
- 用
javap -c反编译，观察字面量是否转为iconst_*或ldc指令； - 用
jclasslib查看常量池，确认static final基本常量是否以CONSTANT_Integer_info等形式存在； - 用
jmap -histo或VisualVM观察堆内存，你会发现没有任何int、boolean类实例——因为根本不存在。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
