JVM规范未规定boolean大小，实际取决于上下文：字段占1字节（对齐填充），数组元素占1字节（底层为byte[]），局部变量可能不存内存；javap显示其运算按int处理，数组不支持位图因规范未要求且HotSpot复用byte[]实现。
boolean 在 JVM 里到底占几个字节？
它不占 1 字节，也不占 4 字节——JVM 规范根本没规定 boolean 的具体存储大小。实际占用取决于上下文：作为字段时，HotSpot 用 1 字节对齐填充；作为数组元素时，boolean[] 被编译成 byte[]，每个元素占 1 字节；局部变量则可能被优化进寄存器，根本不落地。
常见错误现象：new boolean[1000] 占用内存远超 1000 字节（因对象头 + 对齐填充）；用 Unsafe 直接读写 boolean 字段会出错，因为底层是按 byte 或 int 访问的。
- 不要假设
boolean是“最小单位”，JVM 没有位级存储原语 - 别在性能敏感路径上靠“节省 boolean 字段”做优化，字段对齐开销通常比类型本身更大
-
javap -v查看字节码时，boolean运算会被转成iconst_0/iconst_1和ifne/ifeq，说明它在栈上按int处理
为什么 boolean[] 不能直接映射到位图（bit array）？
因为 JVM 规范只要求 boolean[] 支持索引访问和基本逻辑操作，没要求空间效率。HotSpot 实现选择复用 byte[] 的结构，省去了单独设计一种紧凑数组的成本，也避免了位操作带来的原子性、缓存行对齐、JNI 交互等复杂问题。
使用场景：如果你真需要位图，得自己用 long[] + 位运算实现，比如 (bits[index / 64] & (1L 。
立即学习“Java免费学习笔记（深入）”；
- Java 标准库里的
BitSet就是这么干的，但它不是boolean[]的替代品，而是独立容器 - JNI 层传
boolean[]时，JVM 自动转换为jboolean*（定义为unsigned char），不是单 bit 指针 - 序列化
boolean[]时，Protobuf 或 Kryo 都不会压缩它——它们只认语义，不改 JVM 底层布局
boolean 字段在对象内存布局中怎么对齐？
HotSpot 对象头后是实例字段，字段顺序按宽度重排（long/double → int → short/char → byte/boolean），所以 boolean 字段常被塞进前面字段留下的空隙里。但单个 boolean 字段仍会按 1 字节对齐，不会强行压到前一个字段的低位。
参数差异：-XX:+CompactFields（默认开启）允许字段重排；关掉它会让字段严格按源码顺序排列，反而可能增大对象体积。
- 用
java.lang.instrument.Instrumentation.getObjectSize()测量对象大小时，看到的不是“纯字段和”，还包括对齐填充 - 两个相邻
boolean字段大概率共享同一个字节，但你无法通过反射或 Unsafe 去“取其中某一位” - 如果类里只有 1 个
boolean字段 + 1 个Object引用，在 64 位 JVM 上，对象很可能占 24 字节（12 字节对象头 + 8 字节引用 + 4 字节对齐填充）
boolean 和 Boolean 在内存与性能上的真实差距
boolean 是基本类型，无对象开销；Boolean 是包装类，每次自动装箱都可能新建对象（除非值是 true/false，走缓存）。但更隐蔽的问题是：泛型、集合、反射、序列化全会把 boolean 推升为 Boolean，导致隐式分配。
性能影响：方法参数用 Boolean 会导致多一次 null 检查；ConcurrentHashMap<boolean v></boolean> 不合法，必须用 Boolean，而它又不能参与 CAS（AtomicBoolean 才是正确选择）。
- 永远别写
if (flag.equals(true))——flag是Boolean时可能 NPE，是boolean时编译不过 - 日志框架如 SLF4J 接收
Object...，传boolean会触发自动装箱，高频日志下可测出 GC 差异 - Android 上
Boolean.TRUE/Boolean.FALSE缓存是有的，但自定义Boolean实例（如new Boolean(true)）不会复用
