Java基本类型不直接导致内存溢出，但不当使用会间接增大堆内存压力；避免无意义自动装箱拆箱，禁用==比较非缓存范围Integer，循环中勿用Integer作计数器。
Java基本类型本身不直接引发内存溢出，但不当使用会间接导致堆内存压力增大、对象包装开销上升或隐式装箱泄漏。排查重点不在“基本类型用错”，而在于它们如何被误用、放大或掩盖真实内存问题。
避免无意义的自动装箱与拆箱
Integer、Long 等包装类在频繁运算中会持续创建新对象，尤其在循环或集合操作中极易造成堆内存浪费。
- ❌ 错误写法：用 == 比较两个 Integer（值在 -128~127 外时结果为 false）；在 for 循环中写 for (Integer i = 0; i —— 每次都触发装箱和拆箱
- ✅ 正确做法：数值比较统一用 .equals() 或直接用 int/long 原生类型；循环索引一律用 int i；需要缓存时优先复用 Integer.valueOf(n)（它对小整数有缓存）
警惕数组初始化与大基本类型数组的内存代价
基本类型数组虽在堆上分配，但仍是对象，且单个大数组可能直接触发 Requested array size exceeds VM limit 或挤占大量堆空间。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如：new byte[Integer.MAX_VALUE] 在多数 JVM 上会失败；new double[10_000_000] 占用约 80MB，若重复创建或未及时释放，会快速拖垮堆
- 建议：预估容量，用 ArrayList 等动态结构替代盲目扩容；对超大缓冲区（如文件读取），优先使用 ByteBuffer.allocateDirect() 并注意 Direct Memory 配置
线程局部变量与基本类型状态管理
用 ThreadLocal<Integer> 存储计数器看似方便，但若未调用 remove()，会导致线程复用场景下内存持续累积（尤其在线程池中）。
立即学习“Java免费学习笔记（深入）”；
- 更稳妥方式：用原生 int 配合 AtomicInteger 或 LongAdder 实现线程安全计数；若必须用 ThreadLocal，务必在业务逻辑结束前 tl.remove()
- 注意：ThreadLocal 的 key 是弱引用，但 value 是强引用——value 不清理，GC 无法回收对应对象，形成隐式内存泄漏
结合 OOM 日志快速反推基本类型相关线索
当发生 OutOfMemoryError: Java heap space 时，堆转储中高频出现的 [B（byte[]）、[I（int[]）、[C（char[]）等数组实例，往往指向问题根源。
- 用 MAT 查看 “Histogram” → 按大小排序，重点关注 top 3 的数组类；右键 “Merge Shortest Paths to GC Roots” 看谁长期持有这些大数组
- 典型线索：日志解析模块未限制单条日志长度，导致 char[] 持续膨胀；JSON 序列化时未流式处理，把整个响应体读成 byte[] 再解析
