做系统底层和存储相关的开发久了你会发现DRAM刷新这件事特别有意思它看起来就是个定期给电容充电的动作可几乎所有和内存有关的疑难杂症最后都能绕到refresh头上。前两篇基础小知识我们聊了DRAM的基本定位和存储单元结构今天这篇专门把refresh拎出来归类整理一遍从原理、时序、命令类型到工程踩坑把它串成一条线。这套内容适合几类人看刚入行的嵌入式工程师、写内存控制器或驱动的人、做失效分析的硬件工程师还有在服务器上排查偶发内存错误却一头雾水的运维同学。看完你会明白为什么会有tREFI和tRFC这两个参数为什么温度一高数据就变软为什么DRAM明明叫随机存取却偏偏要遵守必须定期刷新这条铁律。1. 一堆电容凭什么存数据DRAM cell工作原理与漏电真相1.1 1T1C单元结构晶体管是开关电容是仓库DRAM的存储单元通常叫1T1C一个晶体管加一个电容。晶体管相当于门字线Word Line负责把门打开位线Bit Line负责把电容里的电荷读出来或者写进去。电容就是存数据的桶桶里有足够电荷代表1几乎没电荷代表0。这个结构和SRAM的6T单元有本质区别。SRAM是靠两个反相器的正反馈锁住状态只要供电不中断状态就是稳的。DRAM不行它存的电荷会跑、会漏没有任何反馈机制能把电平钉在原位。所以DRAM一遍遍地刷新本质上是在跟物理定律抢时间。做系统设计的工程师很容易忽略一个事实DRAM内部真正存储的电荷量非常小。以现代制程来看存储电容大概是十几到几十飞法拉fF量级存的那点电荷只有几个飞库仑fC。对比一下位线上的寄生电容动辄上百飞法拉读出时存储电容要和位线共享电荷电压差很快就被摊薄了。这也是为什么DRAM内部一定要有sense amplifier灵敏放大器这种东西没有它那么微弱的电荷信号根本判不出0和1。1.2 读操作会破坏数据为什么必须充电再写回更反直觉的一点是DRAM的读操作本身就是破坏性的。字线打开后存储电容和位线电荷共享存储节点上的电压会被位线拉走一大截。也就是说你读一次这个cell它自己存的数据就变模糊了。所以读路径上必须配合写回restore动作sense amplifier把读出的微弱电平放大成一个清晰的高/低电平然后再灌回存储电容。这就是为什么DRAM的active/read操作不能像SRAM那样随意也不能把sense amplifier随便释放。一个典型的active命令周期里实际发生的事是先打开字线让存储电容和位线电荷共享sense amplifier感应并放大再把放大后的电平写回存储电容。刷新做的事和读操作高度相似选出某一行打开字线读出所有cell的电平让sense amplifier放大再把电平写回。区别只在于不把数据送到DQ总线上也不走完整的数据通路。换句话说refresh就是在后台偷偷把每一行的数据重新读一遍再写一遍把衰减的电荷补回去。1.3 漏电路径详解数据其实每时每刻都在变淡数据为什么会丢因为存在三条主要漏电路径晶体管关断后的亚阈值漏电subthreshold leakage这是最主要的一条。Word Line为低电平时理论上晶体管应该完全关断但源漏之间仍然会有微小电流流过。存储节点PN结的反向偏置漏电junction leakage工艺越老越明显和温度强相关。电容介质本身的漏电dielectric leakage在高电压应力和高温下会加剧。这些漏电有一个共同特点随温度升高呈指数增长。业界经常用一个粗略的经验规律估算——温度每升高10℃DRAM的保持时间大约减半。这句话听起来简单却是整个温度补偿刷新策略的核心依据后面第5节会展开讲。理解了漏电就能理解为什么JEDEC要给DRAM定一个必须在XX毫秒内刷新一次的约束。数据保持时间retention time这个东西是由最弱的那颗cell决定的不是所有cell的平均水平。生产出来的几十亿颗cell里只要有一颗保持时间特别短整颗颗粒的保持特性就被它拖下水了。2. 64ms和8192行的账tREFI与tRFC如何决定刷新频率2.1 tREFI两次刷新命令之间的间隔从哪来JEDEC标准把DRAM的数据保持时间规定为64ms工业级常温范围内。意思是在满足温度和电压工作条件下任何一行数据从上一次被刷新或写入之后最多64ms内必须再刷新一次否则最小保持性cell也可能丢数据。那么问题来了64ms内要把所有行都刷一遍。一个典型的DDR4颗粒按8K行刷新模式组织也就是8192行。要在这64ms里把8192行全部刷到平均间隔就是64ms ÷ 8192 7.8125μs硬件上不会用一个尴尬的小数做分频行业惯例直接取整成7.8μs。这个平均刷新间隔就是tREFI。如果颗粒支持4K行刷新模式DDR4以后部分大容量颗粒支持那tREFI就可以放宽到15.6μs因为只需要刷新4096行。这里要特别注意术语tREFI里的REF是refresh reference interval它是平均刷新间隔不是单次刷新的时间。单次刷新时间由另一个参数tRFC决定。很多人初学时把这两个参数搞混后面算性能损耗就会算错。2.2 tRFC刷新期间DRAM在忙什么刷新不是瞬间完成的。发一条REF命令后DRAM内部要把当前刷新的那行读出、放大、再写回这个过程需要时间名字叫tRFCRefresh Cycle Time。在tRFC窗口内DRAM基本处于忙碌状态外部只能发NOP或DESELECT这类无害命令真实的读写访问都要排队等着。tRFC的典型值在不同容量、不同工艺节点下差异很大。拿DDR4来说一颗4Gb颗粒的tRFC可以做到260ns左右8Gb/16Gb颗粒可能要350ns甚至更长。容量越大片内行缓冲和bank结构越复杂单次刷新所需的时间通常就越长。JEDEC标准给出的只是最大值上限具体数值一定以数据手册为准。2.3 刷新开销的数学账tRFC/tREFI的占比这会算账很重要。假设DDR4-2400tREFI取7.8μstRFC取260ns那么刷新对内存访问时间的影响大约是260ns ÷ 7800ns ≈ 3.3%意思是理论上只有约96.7%的时间能真正用来做读写访问还没算bank冲突、调度开销和地址映射损失。这个比例看起来不高但在高带宽高并发的服务器场景里3%的带宽损失已经能感知到了。如果环境温度超过85℃刷新周期要求减半tREFI从7.8μs降到3.9μs刷新开销直接翻倍接近6.7%。温度对性能的影响一部分是器件本身漏电加大、速度变慢另一部分就是这个刷新频率加倍带来的。所以很多平台在BIOS里提供double refresh选项本质上就是用性能换可靠性。参数含义DDR4常见值tREFI平均刷新间隔7.8μs常温8K模式tRFC单次刷新阻塞时间260~350ns视容量每次刷新覆盖行数内部计数器递增1行单位窗口刷新次数64ms内8192次8K模式带宽损耗tRFC/tREFI约3.3%~4.5%3. 刷新命令的几种流派Distributed、Burst、Auto、Self3.1 突发刷新与分布式刷新的取舍按刷新时机来分DRAM刷新有两种策略突发刷新Burst Refresh和分布式刷新Distributed Refresh。突发刷新的做法是把64ms需要的8192次刷新一次性连续执行完然后接下来很长一段时间什么都不干。实现逻辑很简单但它有一个致命缺陷——突发刷新期间内存完全不可用读写延迟会飙到一个很难看的水平。现代系统几乎不会采用这种模式。分布式刷新正好相反它把8192次刷新分散到整个64ms窗口里每到tREFI就刷一行刷完立刻释放总线。这样刷新对正常访问的打断是分散的、平滑的延迟峰值小得多。代价是控制器需要维护一个准确的定时器每隔几微秒就要发起一次刷新命令调度复杂度高一些。现代内存控制器无一例外都采用分布式刷新。但严格来说你在实际芯片里看不到纯粹的每7.8μs刷一行因为同一行刷新之间还要考虑某个bank的访问冲突。所以控制器通常会把刷新任务挂在一个队列里在满足时间约束的前提下找合适的窗口插入这就是后面要讲的刷新调度和交错。3.2 自动刷新Auto Refresh现代DDR的标准玩法从SDR SDRAM时代开始JEDEC就规定DRAM刷新采用自动刷新机制。所谓自动指的是外部只需发一条REF命令不用提供行地址DRAM芯片内部自带的刷新行计数器refresh row counter会自己记住上一次刷到哪一行每次REF命令自动对下一行执行刷新。这里有个容易忽略的历史区别在更早的DRAM比如快页模式FPM/EDO时代刷新通常需要外部提供行地址也就是所谓的RAS-only刷新。后来发现这样太费外部控制逻辑才改成CBRCAS before RAS方式再演进到今天的自动刷新。理解这个演进过程就能明白为什么DDR控制器初始化时要先配置好刷新模式而不是随手发个地址就算刷新。自动刷新模式下刷新地址对操作系统和应用完全透明。你不需要知道哪一行正在被刷新也不需要关心刷新计数器在哪个位置这些全部由DRAM内部逻辑搞定。3.3 自刷新Self Refresh低功耗场景下的内部值守自刷新Self Refresh是另一种完全不同的执行机制。它面向的是系统挂起suspend、待机等低功耗场景。控制器发一条Self Refresh Entry命令后DRAM内部开始用自己的定时器和刷新行计数器维护刷新不再依赖外部时钟。此时外部甚至可以把内存时钟停掉整个内存子系统进入极低功耗状态。数据能不能保住完全看片内自刷新电路勤快不勤快。退出自刷新时控制器要发Self Refresh Exit命令并且必须等tXSR时间过去才能恢复正常的读写访问。这个退出时间通常比tRFC还长规格上一般有几百纳秒到微秒级。有些低功耗平台在进出自刷新时延迟抖动很明显正是因为自刷新期间系统的时钟状态变化大退出的恢复序列比较长。LPDDR系列在自刷新上做得很深片内集成温度传感器温度低时自动降低刷新频率温度高时自动加倍刷新目的就是让自刷新电流尽量贴合刚好能保数据的水平。这个特性也叫温度补偿自刷新TCSR和后面要说的温度补偿刷新是两套机制但思想一样。4. REF命令的微观行为从PRE到idle的状态机之旅4.1 为什么REF前必须全bank预充电翻一下DDR4/DDR5协议手册REF命令对bank状态有一个硬性要求所有bank必须处于idle状态。也就是说你想发REF得先确保没有打开的行如果有必须先执行预充电PRE把所有行关掉。这个要求背后的逻辑不复杂。刷新要动用行译码、字线驱动、sense amplifier这些模拟前端资源。如果某个bank还有打开的行它的sense amplifier正保持着那一行的数据这时候去刷新另一行会跟正在服务的数据通路打架轻则破坏数据重则产生串扰。所以协议干脆规定刷新前所有行都要先关上让模拟前端腾出来。从外部时间轴上来看实际经历的事情是控制器根据tREFI倒计时快到期时就要开始准备先把打开的bank全部PRE等tRP过去再发出REF再等tRFC完成最后才能激活新的行继续正常操作。4.2 REF内部发生的三件事读出、放大、写回REF命令进入芯片后片内逻辑会做这么三件事选行根据内部刷新行计数器的当前值选中下一行要刷新的字线。读出放大打开这一行的所有cell到对应的sense amplifiersense amplifier把衰减的电平放大成清晰的高/低电平。写回把放大后的电平再写回存储电容让这一行的电荷恢复到接近满充的状态。整个过程和一次带数据输出的读操作在物理动作上几乎一样唯一区别就是数据不送DQ总线也不更新输出驱动。所以tRFC的时间通常跟tRASActive to Precharge有可比性不是随便定的。理解了这三件事就能明白一个道理刷新后这个cell的数据是真的满血复活了。陈旧的单元电荷被重新充满保存时间窗口从头开始计算。refresh做的是模拟层面的事解决的是电荷不够了的问题这和后面要讲的ECC scrub有本质区别。4.3 refresh与正常读写指令的调度冲突与排队策略既然刷新会阻塞正常访问那控制器就得面对调度问题。一个真实的内存控制器里刷新不是孤零零一条REF它要和其他所有读写命令混在一起仲裁。常见策略是这样的控制器维护一个刷新定时器tREFI快到期时把刷新请求标记为紧急。正常情况下控制器会利用命令总线的空闲缝隙插入REF如果当前一直有连续读写控制器会适当推迟刷新但不能无限推迟。因为每推迟一次有效保持时间就被压缩一截。如果推迟太久就会出现窗口最后不得不连续补刷多条REF的情况这时候内存延迟会突然恶化甚至出现明显毛刺。我在实际系统中见过一种现象大部分时间延迟都很漂亮但每过一段时间正好对应刷新窗口边界某个请求的延迟突然从几十纳秒跳到几微秒。开始还怀疑是CPU调度问题后来抓内存总线才知道是刷新补刷导致。所以做实时系统评估时不能只看平均带宽和平均延迟要看延迟分布的最大尾巴到了哪里。用一个简化的时序示例说明全过程假设tRP15nstRFC350ns 时间轴0ns ~ 15ns PRE命令生效禁止访问 15ns ~ 365ns REF命令执行中禁止访问 365ns之后 可以发ACT正常访问恢复从PRE到ACT能发出至少需要365ns。这个阻塞窗口对一次读写请求来说就是真实感受到的刷新惩罚。5. 温度和功耗压力下刷新策略怎么调整5.1 温度每升高10℃数据寿命差不多减半前面提过漏电路径对温度极其敏感。物理根源在于PN结反向饱和电流和亚阈值电流都随温度指数上升温度越高电荷跑得越快。工程上有个方便的经验法则温度每上升10℃DRAM保持时间大约缩短一半。按这个规律常温下能保64ms的cell到了75℃可能只能保32ms85℃可能只剩16ms左右。当然实际颗粒没那么机械但趋势和量级是对的。这也是为什么高温环境下的服务器内存故障率明显高出低温机房。你看到的随机bit翻转、ECC报错、系统重启相当一部分不是颗粒本身坏了而是刷新窗口已经压不住漏电速度了。系统层面能做的第一件事往往是改善散热第二件事就是把刷新频率提上去。5.2 温度补偿刷新TCR85℃分水岭的取舍DDR3时代开始JEDEC就把温度补偿刷新Temperature Compensated Refresh正式纳入了标准。核心逻辑是温度超过某个阈值通常是85℃时刷新周期减半tREFI从7.8μs变为3.9μs温度降回正常范围后再恢复到标准刷新率。这个切换可以由DRAM自己根据内置温度传感器完成也可以由内存控制器读温度状态后主动改写模式寄存器触发。实际系统中经常看到BIOS里有一个Double Refresh选项打开后无论温度高低都强制按加倍频率刷新。代价是带宽损耗多一截好处是罕见的高温场景下多一重保险。不少做云服务器的人干脆默认开启double refresh因为服务器内存量大、故障影响面广宁可牺牲几个点的性能也不愿在极端天气下批量出问题。这个取舍没有绝对对错但决策时一定要知道性能代价在哪。5.3 DDR5的Fine Granularity Refresh细化粒度来减压DDR5引入了一个值得关注的新特性Fine Granularity RefreshFGR。它把刷新粒度从默认的1x变成可选的2x或4x。默认1x粒度的意思是每一轮刷新窗口里把该刷的行一次性刷完tRFC就是为这一整批刷新预留的时间。2x粒度则把这一批拆成两半每半个tREFI刷一半4x再细拆。粒度越细单次刷新命令的tRFC越短对访问的阻塞窗口越短延迟尖峰越小。代价是刷新命令更频繁控制器的调度压力更大。这其实是在阻塞时长和阻塞次数之间做权衡。对延迟敏感的实时场景短而频繁的刷新比长而稀少的刷新友好得多因为尾延迟更可控。DDR5把这些选择通过模式寄存器开放给系统给了平台设计者更大的调优空间。5.4 低功耗链路里的刷新行为在低功耗设备上刷新是DRAM静态功耗的一大来源。最直接的手段就是靠自刷新模式把刷新频率降到满足数据保持的最低线。LPDDR颗粒内部温度传感器会按照温度分级自动调整自刷新间隔温度低时把刷新率降下来温度高时提上去。还有一点容易被忽略刷新时的电压摆幅和内部电荷泵活动也会耗电。有些控制器在自刷新进入后会进一步降低VDDQ甚至把部分模拟前端断电进一步压低功耗。做功耗评估时不能只看数据手册里某个固定温度点的自刷新电流要把整条温度曲线拉出来看。实测一颗LPDDR4在自刷新状态下的电流随温度变化可以差好几倍。这个差异对电池类产品的影响远比很多人想象得大。6. 从业者视角refresh相关的故障现象与调试经验6.1 retention fault与随机软错误很多人遇到过这种情况服务器偶发ECC可纠正错误错误地址不固定跑一圈内存检测工具全通过换到高温机房或者开启双倍刷新后错误频率明显下降。这大概率就是refresh margin的问题更精确地说是retention fault。某颗cell的保持时间偏短可能只有二三十毫秒正常tREFI7.8μs完全覆盖得了但在某些特定条件下——温度高了、电压低了、刷新被推迟了——就会暴露出保持时间不足的短板。特别要小心两种工况系统suspend/resume前后自刷新进出过程中刷新可能长时间中断弱cell最容易在这个窗口丢数据。高负载时控制器连续推迟刷新到临界点才补刷短暂出现刷新空窗期。做可靠性测试时我会建议专门设计一个弱化刷新用例把tREFI人为调长几倍或者把刷新模式降到最低频率然后满负荷读写跑高温。如果在这种条件下才出错基本就能锁定是retention问题而不是普通的位线短路或cell开路。顺带说一句很多内存测试工具默认不会等64ms才刷新一轮它们跑得很快retention问题在常规stress测试里很容易被漏掉。想真正验证retention必须专门设计低刷新率或高温静置场景。6.2 refresh与ECC scrub是两码事ECC内存能纠正bit翻转但ECC替代不了refresh。refresh解决的是模拟层面的电荷衰减ECC解决的是数字层面的错误检测与纠错两边职责完全不同。服务器里常见的scrub内存巡检指的就是周期性地读取内存区域利用ECC校验逻辑发现可纠正错误然后写回正确数据。这样做可以把单bit错误及时清掉避免多个单bit错误累积成无法纠正的多bit错误。如果一个平台开始大量报scrub错误我不建议第一反应就换内存。先查温度再确认刷新配置是不是被改过比如BIOS里tREFI参数被某些性能优化工具改大了。有一次我排查一个内存随机报错的问题最后发现是某款优化软件把tREFI调到了11μs。这在常温可能还能跑温度一上来就原形毕露。6.3 内存控制器调度刷新队列的实战策略真实的内存控制器在调度刷新时不会死板地每7.8μs发一条REF。它一般会维护一个刷新队列允许刷新任务在一定范围内推迟并设置优先级和紧急阈值。一个比较实用的设计思路是把刷新分成普通刷新和紧急刷新两级。普通刷新可以等待普通访问但等到最大可推迟限额后刷新转入紧急态此时读写请求要主动让路。另外刷新可以和bank交错结合如果一个bank的刷新正在执行其他bank的访问还能继续这就是为什么新一代内存控制器强调per-bank/bank-group级别的刷新能力。对应用开发者来说不需要直接操作这些寄存器但要理解内存延迟的分布。如果业务对时延敏感建议把内存刷新引起的尾延迟纳入性能评估。很多中间件就因为没考虑这个看不到的毛刺在峰值流量时频繁超时。6.4 PSRAM与伪静态存储器的refresh问题如果用过PSRAM伪静态随机存储器你会觉得它很省心外部接口跟SRAM一模一样不需要你关心刷新时序。但它的本质仍然是DRAM cell刷新逻辑被封装在芯片内部由片内自刷新电路完成。省心的代价是延迟不可控。PSRAM内部为了避开刷新冲突随机访问的延迟可能偶尔卡一下。选型时如果对实时性要求苛刻光看平均访问时间还不够要看数据手册里有没有写refresh collide造成的最坏延迟。在极端实时场景里内存读取延迟必须是确定值这时候老老实实用真SRAM或者用容量小但刷新调度可预测的LPDDR可能比PSRAM更合适。补充一句PSRAM和DDR PSRAM在市场上的描述差别很大有的直接用DDR接口有的还是并行SRAM接口但所有PSRAM都绕不开内部刷新这个物理事实。选型之前先搞清楚它的refresh策略比只看带宽参数靠谱得多。Refresh这个东西越往深处挖越觉得它不是定时充个电那么简单。它串起了DRAM cell的物理本质、JEDEC的协议设计、控制器的调度算法还有温度、功耗、可靠性这些工程维度。这几年我在实际项目中踩过的最深的坑就是拿默认配置一路跑到底直到把温度、电压、刷新参数三个变量放到一起做压力测试才暴露出问题。如果你也在调内存相关的东西我的建议很直接先算清楚自己平台的tREFI和tRFC是多少再考虑要不要动它。把刷新的账算明白了内存的大部分疑难杂症就都好谈了。