写代码写了好几年你有没有认真想过这个问题代码里那个int、那个对象在被 CPU 真正读到之前究竟被“安排”成了什么样子我最早产生这个困惑是因为一次线上事故——Java 服务堆内存已经给了 8G依然频繁 Full GC把堆 dump 拉下来发现里面躺着几千万个快照对象而隔壁 C 服务只占 800MB在同样的业务量下却稳如老狗。从那以后我开始系统研究“数据在内存中的存储”这条链路上的每一层操作系统给的是虚拟内存编译器把类型翻译成二进制运行时把对象布局成带元信息的结构回收器又在后台打扫战场。这篇文章就把这条链路从物理层到语言层完整拆一遍适合正在追内存问题、想搞懂 JVM/GC或者好奇 C 语言里 float 打印出来为什么是那个样子的读者。1. 物理内存分配与进程地址空间被“包装”过的真实内存1.1 为什么程序看到的地址不是物理地址很多初学者会有一个直觉我在代码里拿到一个指针指针的值就是内存条上的物理位置。这个直觉在现代操作系统里基本是错的。CPU 访问内存时用的是虚拟地址。内核通过页表把虚拟地址映射到物理页面每次访问都经过 MMU内存管理单元转换。这个设计最大的好处是隔离进程 A 不知道进程 B 在物理内存的什么位置甚至 A 和 B 可以“共用”同一个虚拟地址但映射到完全不同的物理页。这里有个非常容易踩坑的点你看到进程占用了 10GB 虚拟内存VSZ就以为它真的吃掉了 10GB 物理内存这完全是误解。举个实际案例。我用/proc/PID/status看进程内存时主要看两个字段VmRSS当前真正在物理内存中的页大小。这是判断“内存占用高不高”的唯一可靠指标。VmSize虚拟地址空间大小。它包含了所有 mmap 过的文件、共享库、申请但未实际写入的堆页等数值虚高很正常。我处理过一次问题一个 C 服务 VmSize 显示 12GB但 VmRSS 只有 1.2GB。运维同事一口气把机器搞炸了都找不到原因就是因为没看 RSS以为虚拟内存就是物理内存。那什么时候虚拟内存会真正变成物理内存答案是缺页异常。当进程访问一个虚拟页而页表里没有对应物理页时CPU 触发缺页中断内核分配物理页、更新页表、重新执行指令。这个过程就是“按需分配”的本质。所以哪怕你一次性 malloc 了几个 GB只要不写入物理内存几乎不会增加但只要每个页写 1 个字节系统就不得不把整个 4KB 页真实分配出来。1.2 内存分配器你 new 一次底层经历了什么只说 malloc 的话大多数人以为它直接找内核要内存。实际上内核只提供两个基础机制brk和mmap。它们的开销都很大涉及系统调用、内核锁、页表操作如果每次分配 8 字节都走系统调用程序很快就会变成性能灾难。所以 C 语言的堆内存管理通常由分配器在用户态完成。glibc 的 ptmalloc 是 Linux 下最常用的分配器它会向内核批量申请大块内存比如 128KB然后在用户态把这块内存切分成小 chunk 给应用。分配器的核心思路就是缓存 切分。算法细节不用背但要理解两个现象free 一块内存后进程 RSS 往往不会立刻下降。因为分配器把这块 chunk 留在了自己的空闲链表中等下一次 malloc 直接复用。所以你会看到 RSS 稳定在一个高水位这是正常现象不是泄漏。超过mmap_threshold通常 128KB的大分配直接走 mmap而 mmap 分配的内存释放时会立刻归还给内核这也是监控软件看到内存忽高忽低的原因之一。C 的new底层还是调用 mallocJava 的堆则是在启动时一次性向 OS 申请一块大内存默认 1/4 物理内存再自己管理。这套用户态请求-分配器-伙伴系统-物理页的链路是理解所有语言内存行为的底层基础。1.3 内存带宽与 token内存墙到底怎么吃掉算力的很多做 AI 推理的人会频繁看到“内存带宽与 token”这个词因为它直接命中一个核心矛盾算力增长远快于内存带宽增长。DDR5-5600 内存的带宽计算公式是频率 * 位宽 / 8。单通道 5600MHz * 64bit / 8 44.8GB/s双通道约 89.6GB/s。听起来很猛但 LLM 推理是典型的带宽瓶颈场景。7B 规模的模型每生成 1 个 token都要把 KV Cache 重新读一遍。粗略估算7B 模型每个 token 的 KV Cache 约占 0.5MB~1MB取决于层数、head 数和精度。如果生成速度是 20 token/s每秒需要搬运 10MB~20MB 数据这开销直接压在内存带宽上。理解了带宽这个概念你就能明白为什么 JVM 堆的 Java 对象访问比紧凑数组慢——因为对象指针跳转、头字段开销、缓存行利用不充分都会增加对内存带宽的消耗。这也是为什么现代高性能代码总强调局部性和数据紧凑布局。2. 编译器眼中的二进制真相int、float 与字节序的存储细节2.1 float 的位布局为什么 0.10.2 不等于 0.3C 语言的float在内存中的样子和你的直觉完全不同。它遵循 IEEE 754 标准32 位被拆成三部分1 位符号位、8 位指数位、23 位尾数位。以1.0f为例它的十六进制是0x3F800000二进制展开为0 01111111 00000000000000000000000。符号位 0指数位 127尾数位全 0。实际数值是1.xxx * 2^(127-127)隐含的 1 不在存储位里所以是 1.0。为了验证我经常在 Linux 上直接打印原始字节#include stdio.h #include string.h int main() { float f 0.1f; unsigned char *p (unsigned char *)f; for (int i 0; i 4; i) { printf(%02x , p[i]); } printf(\n); return 0; }在一台小端机器上输出是cd cc cc 3d倒过来读就是0x3DCCCCCD。只有 23 位尾数意味着0.1f只能近似表示误差是真实存在的。所以0.1f 0.2f ! 0.3f不是编译器 bug而是浮点数的存储精度天然有限。这个现象在财务计算中是致命的。如果用double或float做金额累加误差会在大量交易后不断累积。我在做支付系统时所有金额统一用整数“分”存储从源头避免浮点误差。这是数据存储设计里的基础常识但网上仍然每天有人问“为什么我的 C 程序算钱不准确”。2.2 负数的补码为什么被擦掉的那一位反而更优雅有符号整数在内存中的存储也是反直觉的。绝大多数机器用补码表示负数最高位是符号位但负数的存储不是简单的“绝对值符号位”而是“取其绝对值的二进制取反加一”。比如-1在 32 位 int 下是0xFFFFFFFF而不是0x80000001。这样做最大的好处是加法和减法共用同一套硬件逻辑不需要单独设计“减法器”。1 (-1)直接走二进制加法会得到0x00000000进位自然溢出被丢弃结果正确。有个很实用的排查经验当你解析二进制协议时如果某个 int 字段打印出来是个巨大的正整数比如4294967295第一反应就应该是“这是一个负数但我用了无符号类型去读它”。这类问题的修复通常很简单把解析类型换成int32_t就行。2.3 大小端同一个文件在两个架构上读出不同的值字节序大小端是数据存储中经典的坑。小端模式低字节存在低地址大端模式高字节存在低地址。x86、ARM 的主流运行模式都是小端而网络协议普遍采用大端也叫网络字节序。处理一个跨平台 MP4 解析项目时我遇到过一个问题同样的代码在 x86 上正常在 ARM 上解析出的文件大小总是大几百倍。排查下来发现只是我没用ntohl做字节序转换。MP4 的 box 大小字段是网络字节序x86 上直接读出来是乱序ARM 上更是完全错位。写一段统一的判断和转换逻辑放在工具层比在每个解析点临时转换要稳妥得多。如果做嵌入式开发比如 RK3588 这类平台跨处理器通信时字节序更是必须统一。大小端问题还有一个连带知识点结构体对齐也会影响存储布局。C 编译器为了对齐访问速度会给结构体插入 padding。比如struct A { char c; int i; };sizeof(struct A)在 32 位下通常是 8而不是 5。因为int要对齐到 4 字节地址。所以如果你把结构体直接写到文件里跨编译器、跨架构版本升级时字段偏移可能完全变了。正确的做法是显式加__attribute__((packed))或者使用序列化协议而不是直接 dump 结构体二进制。3. 对象建在堆上JVM 中的存储布局与内存模型3.1 一个 Java 对象在堆里到底占多少字节Java 程序员习惯了 new 对象但很少人清楚一个对象在堆里长什么样。以 64 位 JVM 开启指针压缩默认为例一个普通对象由三块组成对象头Mark Word 占 8 字节Klass Pointer 压缩后占 4 字节。数组对象额外有 4 字节记录长度。实例数据字段的值按类型排列boolean/byte/char 等各有对齐。对齐填充总大小按 8 字节对齐。我用 openjdk 的 JOLJava Object Layout工具验证过。比如public class User { private long id; private String name; }在 64 位压缩指针下这个对象的栈外大小是 24 字节不包括 name 引用的 String 对象本身。很多初级开发者看到堆容量紧张第一反应是“数据结构太多了”其实更常见的是对象头本身造成的内存浪费。有个实操建议保存大量小对象时优先用基本类型数组或者类似Long/Long的包装结构而不是建几千个对象。同样一个坐标点new Point(x, y)可能吃掉 24 字节而用一个long打包 4 个 short 只占 8 字节。这就是为什么很多高性能框架喜欢用“扁平数据结构”。3.2 分代模型的存储逻辑为什么内存明明还够却频繁 GCJVM 堆内部并非一块简单的连续区域而是分成年轻代和老年代。年轻代又分为 Eden 区和两个 Survivor 区。新对象几乎都在 Eden 分配经历过一次 Minor GC 后还存活的对象升级到 Survivor多次 GC 后仍然存活才会晋升到老年代。为什么要分代因为统计显示绝大多数对象“朝生夕灭”把它们集中放在一个区域GC 时只扫描这块小区域代价低、效果大。查看 JVM 内存状态我一般直接用命令行jmap -heap pid jstat -gcutil pid 1000jstat -gcutil每秒打印一次能看到 Eden 使用率、Old 使用率、FGC 次数。如果 Old 使用率长期在 90% 以上并且不断上升基本可以断定对象晋升过快或者存在泄漏。IDEA 里如果想要直观看到内存启用 “Show Memory Indicator” 功能底部状态栏就能显示堆占用情况。但它显示的只是堆内存看不到 Metaspace、堆外内存所以线上判断仍然以jstat为准。有一个很容易忽略的点JVM 堆并不会在每次 GC 后把内存归还给操作系统。进程可能明明没多少存活对象RSS 依然很高。因为 JVM 倾向于保留它已申请的内存以便下次分配避免重新向 OS 申请。这种情况直接看堆内的 GC 日志反而更准确。如果 RSS 高但堆占用低说明是堆外内存或本地内存的问题不要盲目调大-Xmx。3.3 字符串的驻留池一个 equals 引发的存储位置之争字符串是“数据在内存中的存储”这个话题里最丰富的案例。new String(test)和直接写test的存储位置是有本质区别的。字面量字符串存在于字符串常量池String PoolJVM 在类加载后会把这个test放入池中。new String(test)则会在堆上新建一个 String 对象。两个对象的引用地址不同但内部指向的字符数组可能都复用了常量池里的char[]。曾经有个同事在循环里写new String(someField)一次请求产生几万个重复的字符串对象。虽然这些对象很快被回收但耗尽了年轻代空间导致频繁 GC。后来改成直接引用someField.toString()堆占用直接下降一半。字符串对象本身有 24 字节以上的对象头 字符数组开销数据量大时非常可观。如果遇到字符串去重的场景JDK 8u20 之后可以用-XX:UseStringDeduplication开启字符串去重它会把内容相同的char[]引向同一个数组。但注意这个特性只对长生命周期的老年代对象有效不是万灵药。4. 内存泄漏与溢出存储路径上的“幽灵”4.1 一次 C 字符串内存泄漏排查失衡的 new 与 delete“内存泄漏”这个词C 玩家最熟悉Java 玩家也逃不掉虽然 GC 会兜底但强引用不释放同样是泄漏。我处理过一个 C 服务每次请求都会构造一个std::string用来拼接日志这个字符串被放到了一个静态容器里理论上应该每请求清空但某个异常分支continue直接跳过了清理逻辑。几天后进程 RSS 飙升到了好几个 GB。排查思路是这样的用valgrind --leak-checkfull检查在一个高负载环境下它能定位到没被释放的堆块。但 valgrind 在大型服务上跑起来很慢线上不实用。改用统计手段在关键处记录堆分配总量对比每条请求的字符串长度和对象数量。最终通过 code review 找到了那个continue分支。MFC 程序里常见一种类似问题CString 对象存在成员变量里父窗口销毁了但子窗口没有被正确删除字符串对象的析构函数没执行内存就不会释放。这类问题的本质不是“内存泄漏”这个名字多神秘而是对象的生命周期管理出了问题。C 的 RAII 和智能指针是为了解决这个问题Java 中 try-with-resources 也是。4.2 XSSFWorkbook 内存溢出POI 到底怎么吃掉堆内存Java 后端导出 Excel 是输出内存问题的重灾区。很多人第一次接触 POI直接用XSSFWorkbook加载一个大 Excel 文件结果 JVM 直接 OOM。原因不复杂XSSFWorkbook会把整个工作簿的每个单元格、每行、每列全部建造成 Java 对象驻留在堆中。一个 50 万行、每行 30 列的 Excel对象数量可能达到 1500 万以上。堆不给到 4GB 很难撑住。解决方案是把XSSFWorkbook换成SXSSFWorkbookStreaming Usermodel API。它会把生成的行数据流式写入临时文件只保留滑窗内的一小部分行在内存中SXSSFWorkbook workbook new SXSSFWorkbook(100); // 窗口大小 100 行最关键的注意事项用完要调用workbook.dispose()否则磁盘上的临时文件不会被清理。临时文件默认写在java.io.tmpdir大批量导出时要确认这个目录空间足够。SXSSFWorkbook 不支持随机读取只适合“顺序创建”场景。实际项目中我用它把 50 万行导出堆占用压在 300MB 以内效果立竿见影。4.3 JVM 堆外内存与 Spark 存储目标锁定“隐形内存”Java 程序除了堆内存还存在堆外内存。常见来源包括DirectByteBuffer用于 NIO 的网络读写。JNI 分配的原生内存。Metaspace类元数据区。-Xmx管不到这三块。堆外内存溢出时堆占用正常但进程 RSS 持续膨胀甚至直接被 OS 杀掉。排查时用-XX:MaxDirectMemorySize显式限制 DirectByteBuffer用-XX:MaxMetaspaceSize控制类元数据。Spark 场景里内存管理更复杂。Spark 把内存划分为 Storage Memory缓存 RDD和 Execution Memoryshuffle、join 等。spark.memory.fraction默认 0.6表示堆内存中有 60% 用于这两部分剩下 40% 是预留和保护空间。调参时要防止两类内存互相挤压导致频繁 spill 到磁盘。想要监控 Spark 内部线程的内存分布推荐用spark.executor.metrics选项把 executor 的堆内和堆外用量输出到监控面板。很多人调了半天 Spark 的-Xmx发现效果不佳就是因为没意识到 Spark 的运行内存先要扣掉spark.memory.overhead默认 0.1实际可用堆内存不是你想的那么大。5. 从内存到存储的边界断电之后数据去了哪里5.1 为什么说内存是易失的SRAM、DRAM 与 EEPROM 的存储原理聊到 memory 和 storage 的区别一个核心点就是掉电之后内存主存是易失的外存是非易失的。DRAM 靠电容电荷存储信息电荷会自然泄漏所以需要定期刷新每几十毫秒刷一次。这就是为什么关机后 DRAM 里的数据不翼而飞。和 DRAM 不同EEPROM电可擦可编程只读存储器每个存储单元里有一个浮栅晶体管电荷被注入浮栅后即使断电也能保留很多年。浮栅上有没有电荷决定了晶体管导通阈值的高低也就决定了这个 bit 是 0 还是 1。这就是 BIOS 芯片、传感器配置参数里常见的非易失存储原理。这带来一个设计上的核心约束主存追求速度和密度所以牺牲了持久性外存追求持久性和容量所以读写速度和延迟都远不如内存。嵌入式领域的“混合存储”方案就是在这三种介质之间做权衡。比如 RK3588 平台常见的做法是SPI NOR Flash 放引导程序容量小、随机读快、可靠性高PCIe NVMe SSD 放系统和业务数据容量大、顺序读写快。主要目的就是让不同的数据存到最合适的介质中。5.2 热数据在内存冷数据在对象存储一场按访问温度的交易当数据量超过单机内存时大家开始接触分布式存储和对象存储。曾经不少人问“MinIO 分布式存储的替代者是什么”其实换个角度想MinIO 是对象存储服务中的一个实现它的核心价值是提供 S3 兼容接口让应用把不常访问的数据放进对象存储然后把热数据留在内存缓存里。经典的分层逻辑是内存毫秒级访问容量最小价格最高。SSD/NVMe亚毫秒级访问容量适中。对象存储/NAS秒级或百毫秒级访问容量可以扩展到 PB 级。如果一个图片应用的用户头像热度很高最合理的存储方案就是热数据走内存缓存Redis 或本地 memory冷数据走对象存储而不是把全部图片都塞进 Redis这会让内存规模爆炸。NAS 和对象存储的差异也常常被混淆。NAS 一般提供共享文件语义单位是文件和目录对象存储提供的是桶和对象更适合海量非结构化数据。如果数据规模超过几十 TB并且不需要 POSIX 文件语义对象存储明显更合适。5.3 从“存储位置”看“访问成本”一个完整的决策框架把“数据在内存中的存储”延伸开可以形成一个决策框架数据的访问延迟需求、持久性需求、容量需求共同决定它应该放在哪一层。访问延迟极低且易失可接受的数据如计算中间状态放 DRAM 缓存需要持久化又经常访问的数据放 SSD几乎不访问但必须保留的数据放对象存储。我经常用一张表总结这几个关键维度的差异层级延迟量级持久性典型容量典型成本CPU 寄存器~0.3ns易失几百字节极高L1/L2/L3 Cache~1~80ns易失几 MB~几十 MB高主内存 DRAM~100ns易失几 GB~几 TB中高NVMe SSD~0.1ms非易失几 TB中低对象存储/NAS~几 ms~几十 ms非易失PB 级低这张表在后面做性能优化时非常有用。遇到慢查询先算清楚到底哪一层的访问成本在拖后腿。写数据也是一样如果你在 Java 里大量用ByteArrayOutputStream数据最后要写进内存还是落盘完全取决于你选了哪一层存储。理解每一层的“物理约束”你就不会在设计阶段做出让系统在后面付出巨大代价的决策。写在最后我自己踩过很多次坑之后的一个体会排查任何与存储相关的内存问题都不要只盯着一种语言或一个工具。先确认是虚拟内存虚高还是 RSS 真实占用再判断是堆内还是堆外最后用合适的采样工具jmap、valgrind、perf或者简单的/proc信息逐层定位。有一个小技巧可以分享写长期运行的服务建议在启动脚本里就打印出容器的可用内存和 JVM 的初始堆参数并定期输出jstat摘要。这样出现问题时你能立刻判断是参数配置不对还是程序本身存在对象生命周期失控。数据在内存中的存储本质上就是一张“谁在什么层级、以什么格式、保存多久”的地图。把这张地图刻在脑子里无论是排查内存泄漏还是做架构选型都会比困惑于某一个框架的报错信息要省力得多。