java核心概念需通过实践深挖：arraylist初始容量不等于数组长度，volatile对long/double在现代jvm中主要起内存屏障作用，classloader.loadclass()返回null主因是类名错误或类路径缺失，string.intern()自jdk7起存于堆内字符串常量池。
Java核心概念不是靠“总结”掌握的，而是靠在写代码时反复撞墙、查源码、改字节码才真正理解的。所谓“深度”，往往藏在你调用 ArrayList.add() 却发现扩容逻辑卡顿、或用 ConcurrentHashMap 仍出现数据不一致、又或者 ClassLoader.loadClass() 返回 null 却死活找不到原因的时候。
为什么 new ArrayList(10) 并不能保证底层数组长度就是 10
这是新手最常误解的一点：传入的初始容量只是构造 elementData 数组的参考值，但 JDK 8+ 实际会做向上取整到最近的 2 的幂（比如传 10 → 分配 16），而 JDK 17+ 更进一步，直接使用 ArraysSupport.newArray() 做平台优化，甚至可能延迟分配。更重要的是——这个“初始容量”只影响第一次扩容前的行为，一旦触发 grow()，后续扩容策略由 Arrays.copyOf() 和增长因子（1.5x）共同决定。
- 别依赖
elementData.length判断“实际用了多少空间”，它和size()完全不是一回事 - 如果真要精确控制内存，得看
ArrayList的私有字段（需反射），但生产环境不建议这么做 - 大量小对象频繁 add？考虑预估总量后传参，否则默认无参构造（初始为 0）会导致多次数组复制
volatile 修饰 long 或 double 真的能防止“半个变量”问题吗
能，但仅限于 32 位 JVM 或未开启压缩指针（-XX:-UseCompressedOops）的 64 位 JVM。现代 JDK 默认开启压缩指针，且 HotSpot 对 long/double 的读写做了原子性保证（JVM 规范允许，HotSpot 实现了），所以 volatile 在这里主要起内存屏障作用，而非修复非原子写。
- 真正需要
volatile的场景是：要求可见性 + 禁止重排序，比如状态标志位running - 若用于计数，请直接上
AtomicLong；volatile long counter无法保证自增线程安全 - 注意：
volatile不提供互斥，也不构成锁，它只是告诉 JVM：“这个变量的每次读都必须从主存拿，每次写都必须立刻刷回主存”
ClassLoader.loadClass() 返回 null 的三种真实原因
返回 null 只有一种情况：委托链末端（通常是 BootstrapClassLoader）没找到类，且当前加载器也没覆盖 findClass() 去自己加载。但现实中你看到 null，大概率是因为：
立即学习“Java免费学习笔记（深入）”；
- 传入了错误的二进制名（比如用了路径风格
"com/example/Utils.class"而不是"com.example.Utils"） - 类确实不在 classpath / module path 中，且没有自定义
URLClassLoader或FileSystemClassLoader - 该类被其他 ClassLoader 加载过，而你用的是另一个 ClassLoader 实例（双亲委派下不会重复加载，但不同实例之间无共享）
调试时别只打日志，先确认 getClassLoader().getResource("com/example/Utils.class") 是否返回非 null URL。
String.intern() 在 JDK 7+ 后到底把字符串放哪了
放在堆里，具体是字符串常量池（StringTable），属于 JVM 堆内存的一部分，不再是永久代（PermGen）。这意味着：intern() 不再引发 PermGen OOM，但可能撑爆老年代——尤其当你对大量动态生成的字符串（如 JSON 字段名拼接结果）反复调用时。
- 只有首次调用
intern()才会将字符串实例加入池；后续相同内容调用直接返回池中引用 -
==比较成立的前提是：两个字符串都经过intern()，或其中一个是字面量（字面量自动入池） - 注意：G1 GC 有专门的
-XX:+StringDeduplication参数，它比手动intern()更轻量、更可控，适合清理重复字符串对象
底层细节容易被忽略：StringTable 是个哈希表，默认大小 1009，扩容代价高；频繁 intern() 小字符串可能比直接新建对象还慢。
