晚上十一点本地跑着一个批量任务控制台的日志刷得飞快。你起身接了杯水回来想往回翻找刚才那条报错的行号——滚轮往上顶到天花板最上面那几行根本不是程序的启动日志而是从中间某个查询语句开始的。这种 IDEA 控制台日志被覆盖、显示不全的场景几乎每个用 IntelliJ IDEA 跑 Java、Kotlin、Scala 项目的人都撞上过。我这几年带过几批新人几乎每批都有人问同一个问题控制台的日志缓冲大小在哪改为什么改了还是丢。这篇东西就把这个问题从头到尾摊开讲默认缓冲是多少、配置写在哪个文件、为什么改完不生效、以及比单纯调大缓冲更靠谱的做法是什么。刚装好 IDEA 的新手能照着抄天天跟几十万行日志打交道的老手也能在落盘策略和参数估算那几节里捡到点东西。1. 控制台日志被覆盖到底发生了什么1.1 三种现象别混为一谈很多人一说日志被覆盖脑子里只有一个印象就是控制台上边的内容消失了。但实际上有至少三种完全不同的现象长得像解法差得远。第一种是控制台最顶上那部分输出消失了原本程序启动的前几行不见了剩下的内容从中间某一行开始而程序还在正常运行。第二种是日志文件里也找不到那几行翻遍了 logs 目录最早的记录就是某一时刻之后的。第三种是控制台看着内容不全但如果你把内容复制到文本编辑器里行数又是对得上的只是界面上某些连续重复的行被折叠成了一个小三角。分清楚这三种很重要。第一种是 IDEA 控制台自己的循环缓冲区写满导致的覆盖改 IDEA 的配置就能解决。第二种是日志框架的滚动策略或者文件追加模式出了问题得去改 logback.xml 或者 log4j2.xml。第三种压根不是丢日志是显示层做了折叠你只需要点开那个折叠箭头或者关掉相应的折叠行为就行。判断方法特别简单看控制台现在最上面的那行是不是程序启动的第一行输出。如果是从中间截断的那就基本可以锁定循环缓冲区了。我见过有人为了这个问题折腾了两个小时翻日志框架配置、改 pattern、重装依赖最后发现只是 Run 配置里勾了一个单次运行的缓冲覆盖项跟 logback 一点关系都没有。所以排查之前先花三十秒做这个判断能省掉大量无用功。1.2 循环缓冲区IDE 的自我保护机制要理解为什么会覆盖得先知道 IDEA 的控制台不是一块无限大的画布。IDEA 本身也是一个 JVM 进程控制台里显示的每一行输出都是以字符串的形式存放在这个进程的堆内存里的。一个跑一整夜的定时任务如果每秒钟输出一百行日志一行平均两百字节那一晚上就是好几个 G 的文本量。这些内容如果全部留在内存里不释放IDEA 自己先撑不住轻则疯狂 GC 卡成幻灯片重则直接弹内存不足的提示。所以 IDEA 用的是一种叫循环缓冲区的结构你可以把它想象成一个固定长度的队列。新来的日志从队尾进去队列满了以后队头最老的那条就被挤出去。这就是为什么你往上翻的时候看到的第一条其实是某个中间时刻的输出。默认情况下这个缓冲区的大小是 1024KB也就是 1MB。按一行两百字节粗略估算大概能存五千行左右。对于一个正经的 Spring Boot 项目五千行够不够启动阶段的框架日志加上 MyBatis 打的 SQL往往启动完就已经过半了业务日志再跑几分钟前面的内容自然就没了。这个缓冲区的生命周期是跟着控制台 Tab 走的。你关掉这个 Run 的运行窗口对应的缓冲就释放了。所以它设计的初衷是临时看输出不承担长期留档的职责。想明白这一点后面的所有配置选择就顺理成章了要么把这个临时容器做大一点要么干脆别依赖它让日志落到磁盘上去。2. 三个层级的配置入口先认清各自管什么2.1 单次运行管辖Run/Debug Configurations 的 Logs 标签页打开 Run 或者 Debug 配置的编辑窗口左侧选到你要跑的那个 Application 配置右边有一排标签页找到 Logs。这个页面里有两个跟今天话题直接相关的勾选项。第一个是 Save console output to file勾上之后给一个文件路径IDEA 会把控制台的输出同时写进这个文件从第一行开始不受缓冲区大小的限制。第二个是 Override console cycle buffer size勾上之后可以在后面填一个数字单位是 KB专门给这一次运行用。这两个选项的优先级高于全局配置。也就是说如果你在全局文件里把缓冲区设成了 50MB但这个 Run 配置里勾了 Override 并且填的是 1024那实际生效的就是 1024。这是个非常容易踩的坑后面排查章节还会再提。这个设计其实挺合理日常开发跑个小模块用默认值就够偶尔要跑一个长时间的压测或者数据迁移任务单独给这个配置开大缓冲并落盘不影响其他运行的性能。Logs 页面里还有个 Emulate terminal in output console 选项它主要影响的是 ANSI 颜色码和光标控制字符的解析跟缓冲区大小没有直接关系。但如果你发现日志里的颜色码变成了一堆乱码字符可以试试切换这个开关。它不是主角但知道它的作用范围能帮你少走弯路。2.2 全局默认值idea.properties 里的 idea.cycle.buffer.size真正决定所有新创建的运行配置默认用多大缓冲的是 IDEA 平台级的属性文件 idea.properties。这个文件里有一个键叫 idea.cycle.buffer.size单位是 KB。你可以在里面写具体数字比如 10240 表示 10MB也可以写 disabled 来关闭循环覆盖让所有输出都留在内存里。这里必须强调一点idea.properties 不在你的项目目录里也不在依赖里它是 IDE 安装目录或者用户配置目录下的一个文件。很多人搜教程搜到在 bin 目录下找到 idea.properties照着改了结果发现没生效原因在下一节详细说。另外提醒一句这个文件里原本就有很多以井号开头的注释和默认值你只需要在末尾追加自己的配置行别把原有内容删了也别在行中间乱插属性文件对格式还是挺敏感的。顺便说个历史遗留问题。在比较老的 IDEA 版本里这个值可能在 Registry 里用 Help 菜单下的 Find Action 搜索 Registry 打开然后按 cycle 这个关键词过滤能看到类似 console cycle buffer size 的条目。不同版本的键名和位置有差异这也是为什么你从不同博客抄来的步骤会对不上。我的建议是以属性文件为准Registry 那条路当作备用方案实在找不到再去看。2.3 应用侧落盘日志框架才是长期方案前面两个入口解决的都是看得见的问题而日志框架解决的是留得住的问题。一个成熟的看法是控制台是给人快速扫一眼的文件才是用来回溯和分析的。不管你把这个缓冲区调到多大只要程序跑得足够久它总会写满而且把它调得特别大代价是 IDE 进程的内存占用这笔账后面会算。我一般建议团队里立个规矩任何要跑超过十分钟的任务日志必须落盘且必须有滚动策略。控制台缓冲区给个中等偏上的值够你现场看一眼异常栈就够了。真正要排查问题的时候用 grep 或者 findstr 去文件里捞效率和可靠性都远高于在控制台里用滚轮翻。这话听起来像正确的废话但我见过太多人明明有日志文件还是在控制台里翻得眼睛发酸。具体怎么配在 3.4 节会给一份可以直接抄的 logback 配置。如果你的项目用的是 log4j2 或者 JUL思路完全一样只是标签名和参数名换了写法概念是对应的。3. 一步步改从 1024KB 到自定义容量3.1 新建个人 idea.properties别动安装目录正确的改法是走 Help 菜单里的 Edit Custom Properties。点了之后如果你之前没有个人配置文件IDEA 会提示你要不要新建一个确认即可它会在用户配置目录下生成一个 idea.properties并自动用编辑器打开。在这个文件里写上你的配置保存然后重启 IDE。重启这一步不能省平台属性是在启动阶段读取的。为什么强烈建议用这个入口而不是直接去改安装目录下的 bin/idea.properties有三个理由。第一安装目录下的文件属于 IDE 本体升级或者修复安装的时候很可能被覆盖你改的东西就丢了。第二很多同学是用 Toolbox 之类的工具管理多个版本的安装目录本身会变动路径不稳定。第三多个项目、多个 IDE 版本可能共用一套安装目录在安装目录里改会影响所有人在个人配置目录里改只影响你自己。不同操作系统下这个用户配置目录的位置不一样我整理了一张表方便你直接去找对应的 idea.properties操作系统配置目录典型位置版本号以你实际安装的为准Windows%APPDATA%\JetBrains\IntelliJIdea2024.1\macOS~/Library/Application Support/JetBrains/IntelliJIdea2024.1/Linux~/.config/JetBrains/IntelliJIdea2024.1/如果你不确定自己机器上到底是哪个目录最稳妥的办法是用 Find Action 搜索 Show Log in Explorer 或者 Show Log in Finder先打开日志所在目录idea.properties 通常就在它的旁边或者上一级。实在找不到就用 IDE 自带的 Edit Custom Properties 入口让工具帮你建别硬找。配置内容本身很简单在文件末尾追加一行# 控制台循环缓冲区大小单位 KB填 disabled 表示不做循环覆盖 idea.cycle.buffer.size10240改完之后保存重启 IDEA。有一点要提醒某些版本对 disabled 这个写法的解析不太一样如果你写了 disabled 之后发现控制台行为和之前没区别先换成一个大数字试试比如 102400。属性值解析失败时IDE 一般不会弹窗报错而是静默地用了默认值这就是很多人觉得改了没用的原因之一。3.2 容量怎么估算填多少合适拍脑袋填数字是不行的容易要么不够用要么把 IDE 拖慢。我常用的估算方法是这样的先估一下单行日志的平均长度。一条典型的带时间戳、线程名、类名、行号、消息体的日志英文环境下大概在一百五十到两百五十字节之间如果消息里带中文、带 JSON 结构体或者带 SQL单行冲到五百字节以上很常见带堆栈的异常行更是能到好几 KB。用这个数乘以你预期的最大行数就是需要的容量。举几个具体例子单行按两百字节算你要保留十万行大概需要 20000000 字节也就是约 19MB向上取整填 20480 比较合适。如果要保留五十万行大概 95MB那就要填 102400 左右了这时候就该认真考虑内存开销了。下面这张表是我平时给团队的建议档位填写值KB大致容量适用场景需要留意的点1024默认约 1MB短时间运行的单元测试、小工具长任务必丢前段日志10240约 10MB常规 Web 应用开发、单次调试多数场景够用推荐起点51200约 50MB长时间跑的数据处理、批量任务注意 IDE 内存占用上升102400 以上100MB 起必须完整看到全过程的特殊排查建议同时落盘别只靠内存disabled不限制极短时间但输出极密的场景高频长跑有 OOM 风险这里有个很多人忽略的细节JVM 里字符串的内存开销不等于文本本身的字节数。在开启了紧凑字符串的情况下纯 ASCII 文本大致是每字符一字节但只要有中文、有非拉丁字符就可能退化成每字符两字节甚至更多。所以填了 10MB 的缓冲实际内存占用可能是 15MB 到 20MB。做容量规划的时候把这个系数带上心里会更有底。3.3 改完怎么验证生效改完配置不验证等于没改。我一般用一个二十行左右的小程序来测逻辑就是往控制台打 N 行带序号的日志然后往上翻看第 1 行还在不在。Java 版本大概长这样public class BufferTest { public static void main(String[] args) { String padding x.repeat(180); // 让每行长度接近真实日志 for (int i 1; i 200000; i) { System.out.println(NO. i padding); } System.out.println(done); } }跑完以后把控制台拖到最顶上如果能看到 NO.1说明缓冲至少装下了这二十万行如果最上面是 NO.87342 之类的中间值说明容量还不够或者配置没生效。这个测试的好处是输出长度均匀可控能把容量的边界试出来。除了这个直观测试还有一条更硬的验证路径看 IDE 自己的日志。用 Show Log in Explorer 打开 idea.log搜索 cycle 或者 buffer 相关的行看看有没有属性解析异常的记录。另外改完配置重启后随便建一个新的 Run 配置打开 Logs 标签页看 Override console cycle buffer size 那个勾选框旁边有没有显示你设置的默认值。不同版本的界面表现不太一样有的会直接把全局值填在输入框里作为灰字提示有的不会显示这个只能作为参考主要还得靠上面的实测。注意验证的时候一定要用一个全新的运行配置别在旧配置上测。旧配置可能固化了当时创建时的参数容易得出错误结论。3.4 配套的 logback 落盘与滚动配置光调 IDE 缓冲只是治标。真正让我晚上睡得着觉的是下面这份 logback 配置。它的思路很直白控制台照常输出方便现场看同时所有日志写进文件按天和大小滚动只保留最近一段时间总量再封个顶防止磁盘被塞满。configuration appender nameCONSOLE classch.qos.logback.core.ConsoleAppender encoder pattern%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appender appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/app.log/file rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePatternlogs/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxFileSize50MB/maxFileSize maxHistory7/maxHistory totalSizeCap3GB/totalSizeCap /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appender root levelINFO appender-ref refCONSOLE/ appender-ref refFILE/ /root /configuration几个参数值得展开说。maxFileSize 控制单个文件到多大就切一份50MB 是个折中值文件小了好打开太大了编辑器加载会卡。maxHistory 是保留多少天写 7 就是一周超过的自动删除。totalSizeCap 是总量天花板这个参数很多人不写结果就是日志文件名有历史限制但总量还是可能堆到几十个 G尤其是单天日志量特别大的服务。三个参数的关系是先按大小切再按天归档最后按总量从最老的开始删。如果你担心日志输出阻塞业务线程可以在 FILE 外面再包一层异步appender nameASYNC_FILE classch.qos.logback.classic.AsyncAppender queueSize8192/queueSize discardingThreshold0/discardingThreshold neverBlockfalse/neverBlock appender-ref refFILE/ /appenderqueueSize 是队列长度满了之后的处理策略由 discardingThreshold 和 neverBlock 决定。把 discardingThreshold 设成 0 表示队列里的消息不主动丢弃neverBlock 设成 true 表示队列满了就直接不写绝不阻塞业务线程。这两个值怎么选取决于你更怕丢日志还是更怕业务卡顿。我的经验是核心交易类的日志设成不丢辅助性的诊断日志设成不阻塞。3.5 不想动 IDE 配置时的替代做法有时候你没有权限改 IDE 配置或者就是懒得重启也有办法。最直接的是用 2.1 节提到的 Save console output to file路径填到项目下的 logs 目录连日志框架都不用改控制台输出会从第一行开始完整落盘。缺点是它只记录控制台实际收到的内容如果程序自己用了异步输出顺序上可能和文件里略有出入。另一个思路是从启动命令入手把标准输出和标准错误重定向到文件再用命令行实时跟随。在 Linux 或者 macOS 下大概是这样java -jar app.jar logs/stdout.log 21 tail -f logs/stdout.logWindows 下对应的写法是用 cmd 的重定向配合 PowerShell 的读取java -jar app.jar logs\stdout.log 21 powershell -Command Get-Content logs\stdout.log -Wait -Tail 100这套做法把查看这件事从 IDE 里搬到了终端好处是终端的滚动缓冲可以设得非常大而且完全不受 IDE 内存策略的影响。缺点也明显没法直接点日志里的类名和行号跳转调试体验会下降。所以我一般只在跑长任务、重任务的时候这么干日常开发还是老老实实待在 IDE 里。4. 排查速查改了不生效的七种情况4.1 逐条对照表这是我这些年攒下来的改了没用清单基本覆盖了九成以上的情况现象大概率原因处理办法改完完全没变化改的是安装目录下的文件实际读取的是用户配置目录用 Edit Custom Properties 入口重新建一份改完完全没变化修改后没有重启 IDE完整退出并重新启动不是关窗口值看起来生效了但日志还是丢该运行配置勾了 Override console cycle buffer size取消勾选或者把值一起改大只有某个项目有问题该项目用了独立的启动脚本绕过了 IDE 的运行配置检查脚本里的输出重定向和日志框架配置数字填了但感觉容量不对属性单位是 KB误按 MB 填写重新核对数量级10MB 要写 10240写了 disabled 后行为异常当前版本对这个值的解析不一致换成一个大数字比如 102400多个版本都装了改了一个没反应改的不是当前实际运行的那个版本的配置目录从 About 里确认版本号和安装来源再定位目录表格之外再补一个隐蔽的坑属性文件里不允许中文全角字符混在里面尤其是你从网页复制粘贴配置行的时候很容易把等号或者数字粘贴成全角。肉眼看着一模一样解析器就是认不出来。遇到怎么都不生效的情况把那一行删掉手敲一遍往往就好了。这个坑我踩过不止一次。4.2 缓冲开太大之后的新问题把缓冲从 1MB 调到 100MB解决了看不到前段日志的问题但引入了新的问题得提前有心理准备。首先是 IDE 的内存占用会上去尤其是同时开着好几个运行窗口的时候每个窗口都有自己的缓冲。其次是 IDE 在做全量索引、代码分析这些本来就吃内存的操作时可用的堆空间被压缩卡顿感会变明显。第三如果日志里有特别大的对象打印比如一个几 MB 的 JSON单行就能吃掉不少缓冲这种时候单纯加容量性价比很低。我个人的经验阈值是 50MB 左右。超过这个数就该换思路了——要么减少输出量把日志级别调高屏蔽掉那些没营养的框架 DEBUG要么改成写文件用命令行工具去看。把内存当日志仓库用从来都不是一个好选择。4.3 我常用的一套组合配置说一套我在实际项目里固定使用的配置组合你可以直接照搬。IDE 层面idea.properties 里设 10240也就是 10MB覆盖绝大多数调试场景遇到长任务单独在 Run 配置里勾 Save console output to file。项目层面logback 里同时挂 ConsoleAppender 和 RollingFileAppender滚动的三个参数按 50MB、7 天、3GB 来配。日志级别上业务代码用 INFO框架和第三方库统一压到 WARN只在需要时临时给某个包开 DEBUG。这套组合跑下来日常开发几乎不会再遇到日志去哪儿了的问题。真要回溯三天前的某次异常直接去 logs 目录按时间找文件就行比在控制台里翻靠谱得多。控制台的角色回归到它该有的样子一眼扫过去看有没有红字看完就翻篇。5. 几个只有天天看日志的人才会注意的细节5.1 重复行折叠与假丢日志IDEA 的控制台有个很实用的功能连续多行完全相同的输出会被折叠成一个带数字的提示左边有个小三角可以点开。这个功能在日志大量重复的时候非常友好但也制造了不少日志被覆盖的误报。判断方法很简单折叠的地方会明确显示重复的次数字面意思是还有 XX 行相同内容跟缓冲区溢出那种从中间断掉的表现完全不同。真丢了是找不到开头折叠是行都在只是被收起来了。另外还有一个容易误判的情况某些框架在控制台里输出回车符来做进度条刷新这种动态刷新的行在日志文件里会变成一长串覆盖的内容在控制台里看着则一直在变。如果你发现日志文件里有一堆奇怪的字符先去程序里搜一下有没有用回车符做进度提示的代码八成就是它。5.2 中文乱码与编码链路日志里的中文变成问号或者方块这个问题跟缓冲大小没关系但经常和它一起出现因为大家都是在日志不正常这个现象下把两件事混在一起排查。整条链路有三个编码点源码文件的编码、编译时的编码参数、日志输出时的编码。Maven 项目里可以在编译插件里显式指定源码和报告编码日志框架的 encoder 里也要写上 charset前面那份 logback 配置里的 UTF-8 就是干这个用的。这三个点只要有一个不对中文就会出问题表现可能是全是问号也可能是一半对一半错。在 Windows 上还要额外注意一点控制台默认代码页有时候和 UTF-8 不一致导致 IDE 里看着正常一旦用命令行重定向到文件就乱码。这种情况可以在启动参数里加上文件编码相关的设置或者干脆让日志框架统一用 UTF-8 输出从源头统一比事后猜编码要省事得多。5.3 团队协作里的配置约定idea.properties 是个人配置进不了版本库也不该进版本库。但日志框架的配置文件是项目资产应该提交到 resources 目录并且全组统一。这里有个常见的翻车点有人本地为了调试把某个包的日志级别改成了 DEBUG忘了改回去提交上去之后所有人的日志量暴涨控制台缓冲瞬间被打满于是又有人来问日志怎么又被覆盖了。所以项目里的日志级别最好集中在配置文件的一处管理别散落在代码里用编程方式改。还有一点值得提醒.idea 目录下有相当一部分文件是个人环境相关的比如运行配置里如果勾了 Save console output to file 并写了本机绝对路径这个文件提交上去之后别人拉下来会因为路径不存在而报错或者行为异常。团队里最好约定清楚哪些文件提交、哪些忽略运行配置这类东西要么不提交要么用相对路径。最后分享一个我自己用顺手的小技巧给日志的 pattern 里固定加上线程名和简化的类名也就是 %thread 和 %logger{36} 这两个占位符。日志丢不丢是一回事丢的时候能不能快速判断是哪个模块在疯狂输出是另一回事。有了这两个字段你一眼就能看出是某个定时任务在刷屏还是某个连接池在做健康检查。定位到输出源头之后压级别、加过滤条件这些动作才有地方落。多数时候把噪音降下去比把缓冲区调大要有效得多。
IntelliJ IDEA 控制台日志被覆盖？循环缓冲区与日志落盘配置
晚上十一点本地跑着一个批量任务控制台的日志刷得飞快。你起身接了杯水回来想往回翻找刚才那条报错的行号——滚轮往上顶到天花板最上面那几行根本不是程序的启动日志而是从中间某个查询语句开始的。这种 IDEA 控制台日志被覆盖、显示不全的场景几乎每个用 IntelliJ IDEA 跑 Java、Kotlin、Scala 项目的人都撞上过。我这几年带过几批新人几乎每批都有人问同一个问题控制台的日志缓冲大小在哪改为什么改了还是丢。这篇东西就把这个问题从头到尾摊开讲默认缓冲是多少、配置写在哪个文件、为什么改完不生效、以及比单纯调大缓冲更靠谱的做法是什么。刚装好 IDEA 的新手能照着抄天天跟几十万行日志打交道的老手也能在落盘策略和参数估算那几节里捡到点东西。1. 控制台日志被覆盖到底发生了什么1.1 三种现象别混为一谈很多人一说日志被覆盖脑子里只有一个印象就是控制台上边的内容消失了。但实际上有至少三种完全不同的现象长得像解法差得远。第一种是控制台最顶上那部分输出消失了原本程序启动的前几行不见了剩下的内容从中间某一行开始而程序还在正常运行。第二种是日志文件里也找不到那几行翻遍了 logs 目录最早的记录就是某一时刻之后的。第三种是控制台看着内容不全但如果你把内容复制到文本编辑器里行数又是对得上的只是界面上某些连续重复的行被折叠成了一个小三角。分清楚这三种很重要。第一种是 IDEA 控制台自己的循环缓冲区写满导致的覆盖改 IDEA 的配置就能解决。第二种是日志框架的滚动策略或者文件追加模式出了问题得去改 logback.xml 或者 log4j2.xml。第三种压根不是丢日志是显示层做了折叠你只需要点开那个折叠箭头或者关掉相应的折叠行为就行。判断方法特别简单看控制台现在最上面的那行是不是程序启动的第一行输出。如果是从中间截断的那就基本可以锁定循环缓冲区了。我见过有人为了这个问题折腾了两个小时翻日志框架配置、改 pattern、重装依赖最后发现只是 Run 配置里勾了一个单次运行的缓冲覆盖项跟 logback 一点关系都没有。所以排查之前先花三十秒做这个判断能省掉大量无用功。1.2 循环缓冲区IDE 的自我保护机制要理解为什么会覆盖得先知道 IDEA 的控制台不是一块无限大的画布。IDEA 本身也是一个 JVM 进程控制台里显示的每一行输出都是以字符串的形式存放在这个进程的堆内存里的。一个跑一整夜的定时任务如果每秒钟输出一百行日志一行平均两百字节那一晚上就是好几个 G 的文本量。这些内容如果全部留在内存里不释放IDEA 自己先撑不住轻则疯狂 GC 卡成幻灯片重则直接弹内存不足的提示。所以 IDEA 用的是一种叫循环缓冲区的结构你可以把它想象成一个固定长度的队列。新来的日志从队尾进去队列满了以后队头最老的那条就被挤出去。这就是为什么你往上翻的时候看到的第一条其实是某个中间时刻的输出。默认情况下这个缓冲区的大小是 1024KB也就是 1MB。按一行两百字节粗略估算大概能存五千行左右。对于一个正经的 Spring Boot 项目五千行够不够启动阶段的框架日志加上 MyBatis 打的 SQL往往启动完就已经过半了业务日志再跑几分钟前面的内容自然就没了。这个缓冲区的生命周期是跟着控制台 Tab 走的。你关掉这个 Run 的运行窗口对应的缓冲就释放了。所以它设计的初衷是临时看输出不承担长期留档的职责。想明白这一点后面的所有配置选择就顺理成章了要么把这个临时容器做大一点要么干脆别依赖它让日志落到磁盘上去。2. 三个层级的配置入口先认清各自管什么2.1 单次运行管辖Run/Debug Configurations 的 Logs 标签页打开 Run 或者 Debug 配置的编辑窗口左侧选到你要跑的那个 Application 配置右边有一排标签页找到 Logs。这个页面里有两个跟今天话题直接相关的勾选项。第一个是 Save console output to file勾上之后给一个文件路径IDEA 会把控制台的输出同时写进这个文件从第一行开始不受缓冲区大小的限制。第二个是 Override console cycle buffer size勾上之后可以在后面填一个数字单位是 KB专门给这一次运行用。这两个选项的优先级高于全局配置。也就是说如果你在全局文件里把缓冲区设成了 50MB但这个 Run 配置里勾了 Override 并且填的是 1024那实际生效的就是 1024。这是个非常容易踩的坑后面排查章节还会再提。这个设计其实挺合理日常开发跑个小模块用默认值就够偶尔要跑一个长时间的压测或者数据迁移任务单独给这个配置开大缓冲并落盘不影响其他运行的性能。Logs 页面里还有个 Emulate terminal in output console 选项它主要影响的是 ANSI 颜色码和光标控制字符的解析跟缓冲区大小没有直接关系。但如果你发现日志里的颜色码变成了一堆乱码字符可以试试切换这个开关。它不是主角但知道它的作用范围能帮你少走弯路。2.2 全局默认值idea.properties 里的 idea.cycle.buffer.size真正决定所有新创建的运行配置默认用多大缓冲的是 IDEA 平台级的属性文件 idea.properties。这个文件里有一个键叫 idea.cycle.buffer.size单位是 KB。你可以在里面写具体数字比如 10240 表示 10MB也可以写 disabled 来关闭循环覆盖让所有输出都留在内存里。这里必须强调一点idea.properties 不在你的项目目录里也不在依赖里它是 IDE 安装目录或者用户配置目录下的一个文件。很多人搜教程搜到在 bin 目录下找到 idea.properties照着改了结果发现没生效原因在下一节详细说。另外提醒一句这个文件里原本就有很多以井号开头的注释和默认值你只需要在末尾追加自己的配置行别把原有内容删了也别在行中间乱插属性文件对格式还是挺敏感的。顺便说个历史遗留问题。在比较老的 IDEA 版本里这个值可能在 Registry 里用 Help 菜单下的 Find Action 搜索 Registry 打开然后按 cycle 这个关键词过滤能看到类似 console cycle buffer size 的条目。不同版本的键名和位置有差异这也是为什么你从不同博客抄来的步骤会对不上。我的建议是以属性文件为准Registry 那条路当作备用方案实在找不到再去看。2.3 应用侧落盘日志框架才是长期方案前面两个入口解决的都是看得见的问题而日志框架解决的是留得住的问题。一个成熟的看法是控制台是给人快速扫一眼的文件才是用来回溯和分析的。不管你把这个缓冲区调到多大只要程序跑得足够久它总会写满而且把它调得特别大代价是 IDE 进程的内存占用这笔账后面会算。我一般建议团队里立个规矩任何要跑超过十分钟的任务日志必须落盘且必须有滚动策略。控制台缓冲区给个中等偏上的值够你现场看一眼异常栈就够了。真正要排查问题的时候用 grep 或者 findstr 去文件里捞效率和可靠性都远高于在控制台里用滚轮翻。这话听起来像正确的废话但我见过太多人明明有日志文件还是在控制台里翻得眼睛发酸。具体怎么配在 3.4 节会给一份可以直接抄的 logback 配置。如果你的项目用的是 log4j2 或者 JUL思路完全一样只是标签名和参数名换了写法概念是对应的。3. 一步步改从 1024KB 到自定义容量3.1 新建个人 idea.properties别动安装目录正确的改法是走 Help 菜单里的 Edit Custom Properties。点了之后如果你之前没有个人配置文件IDEA 会提示你要不要新建一个确认即可它会在用户配置目录下生成一个 idea.properties并自动用编辑器打开。在这个文件里写上你的配置保存然后重启 IDE。重启这一步不能省平台属性是在启动阶段读取的。为什么强烈建议用这个入口而不是直接去改安装目录下的 bin/idea.properties有三个理由。第一安装目录下的文件属于 IDE 本体升级或者修复安装的时候很可能被覆盖你改的东西就丢了。第二很多同学是用 Toolbox 之类的工具管理多个版本的安装目录本身会变动路径不稳定。第三多个项目、多个 IDE 版本可能共用一套安装目录在安装目录里改会影响所有人在个人配置目录里改只影响你自己。不同操作系统下这个用户配置目录的位置不一样我整理了一张表方便你直接去找对应的 idea.properties操作系统配置目录典型位置版本号以你实际安装的为准Windows%APPDATA%\JetBrains\IntelliJIdea2024.1\macOS~/Library/Application Support/JetBrains/IntelliJIdea2024.1/Linux~/.config/JetBrains/IntelliJIdea2024.1/如果你不确定自己机器上到底是哪个目录最稳妥的办法是用 Find Action 搜索 Show Log in Explorer 或者 Show Log in Finder先打开日志所在目录idea.properties 通常就在它的旁边或者上一级。实在找不到就用 IDE 自带的 Edit Custom Properties 入口让工具帮你建别硬找。配置内容本身很简单在文件末尾追加一行# 控制台循环缓冲区大小单位 KB填 disabled 表示不做循环覆盖 idea.cycle.buffer.size10240改完之后保存重启 IDEA。有一点要提醒某些版本对 disabled 这个写法的解析不太一样如果你写了 disabled 之后发现控制台行为和之前没区别先换成一个大数字试试比如 102400。属性值解析失败时IDE 一般不会弹窗报错而是静默地用了默认值这就是很多人觉得改了没用的原因之一。3.2 容量怎么估算填多少合适拍脑袋填数字是不行的容易要么不够用要么把 IDE 拖慢。我常用的估算方法是这样的先估一下单行日志的平均长度。一条典型的带时间戳、线程名、类名、行号、消息体的日志英文环境下大概在一百五十到两百五十字节之间如果消息里带中文、带 JSON 结构体或者带 SQL单行冲到五百字节以上很常见带堆栈的异常行更是能到好几 KB。用这个数乘以你预期的最大行数就是需要的容量。举几个具体例子单行按两百字节算你要保留十万行大概需要 20000000 字节也就是约 19MB向上取整填 20480 比较合适。如果要保留五十万行大概 95MB那就要填 102400 左右了这时候就该认真考虑内存开销了。下面这张表是我平时给团队的建议档位填写值KB大致容量适用场景需要留意的点1024默认约 1MB短时间运行的单元测试、小工具长任务必丢前段日志10240约 10MB常规 Web 应用开发、单次调试多数场景够用推荐起点51200约 50MB长时间跑的数据处理、批量任务注意 IDE 内存占用上升102400 以上100MB 起必须完整看到全过程的特殊排查建议同时落盘别只靠内存disabled不限制极短时间但输出极密的场景高频长跑有 OOM 风险这里有个很多人忽略的细节JVM 里字符串的内存开销不等于文本本身的字节数。在开启了紧凑字符串的情况下纯 ASCII 文本大致是每字符一字节但只要有中文、有非拉丁字符就可能退化成每字符两字节甚至更多。所以填了 10MB 的缓冲实际内存占用可能是 15MB 到 20MB。做容量规划的时候把这个系数带上心里会更有底。3.3 改完怎么验证生效改完配置不验证等于没改。我一般用一个二十行左右的小程序来测逻辑就是往控制台打 N 行带序号的日志然后往上翻看第 1 行还在不在。Java 版本大概长这样public class BufferTest { public static void main(String[] args) { String padding x.repeat(180); // 让每行长度接近真实日志 for (int i 1; i 200000; i) { System.out.println(NO. i padding); } System.out.println(done); } }跑完以后把控制台拖到最顶上如果能看到 NO.1说明缓冲至少装下了这二十万行如果最上面是 NO.87342 之类的中间值说明容量还不够或者配置没生效。这个测试的好处是输出长度均匀可控能把容量的边界试出来。除了这个直观测试还有一条更硬的验证路径看 IDE 自己的日志。用 Show Log in Explorer 打开 idea.log搜索 cycle 或者 buffer 相关的行看看有没有属性解析异常的记录。另外改完配置重启后随便建一个新的 Run 配置打开 Logs 标签页看 Override console cycle buffer size 那个勾选框旁边有没有显示你设置的默认值。不同版本的界面表现不太一样有的会直接把全局值填在输入框里作为灰字提示有的不会显示这个只能作为参考主要还得靠上面的实测。注意验证的时候一定要用一个全新的运行配置别在旧配置上测。旧配置可能固化了当时创建时的参数容易得出错误结论。3.4 配套的 logback 落盘与滚动配置光调 IDE 缓冲只是治标。真正让我晚上睡得着觉的是下面这份 logback 配置。它的思路很直白控制台照常输出方便现场看同时所有日志写进文件按天和大小滚动只保留最近一段时间总量再封个顶防止磁盘被塞满。configuration appender nameCONSOLE classch.qos.logback.core.ConsoleAppender encoder pattern%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appender appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/app.log/file rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePatternlogs/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxFileSize50MB/maxFileSize maxHistory7/maxHistory totalSizeCap3GB/totalSizeCap /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appender root levelINFO appender-ref refCONSOLE/ appender-ref refFILE/ /root /configuration几个参数值得展开说。maxFileSize 控制单个文件到多大就切一份50MB 是个折中值文件小了好打开太大了编辑器加载会卡。maxHistory 是保留多少天写 7 就是一周超过的自动删除。totalSizeCap 是总量天花板这个参数很多人不写结果就是日志文件名有历史限制但总量还是可能堆到几十个 G尤其是单天日志量特别大的服务。三个参数的关系是先按大小切再按天归档最后按总量从最老的开始删。如果你担心日志输出阻塞业务线程可以在 FILE 外面再包一层异步appender nameASYNC_FILE classch.qos.logback.classic.AsyncAppender queueSize8192/queueSize discardingThreshold0/discardingThreshold neverBlockfalse/neverBlock appender-ref refFILE/ /appenderqueueSize 是队列长度满了之后的处理策略由 discardingThreshold 和 neverBlock 决定。把 discardingThreshold 设成 0 表示队列里的消息不主动丢弃neverBlock 设成 true 表示队列满了就直接不写绝不阻塞业务线程。这两个值怎么选取决于你更怕丢日志还是更怕业务卡顿。我的经验是核心交易类的日志设成不丢辅助性的诊断日志设成不阻塞。3.5 不想动 IDE 配置时的替代做法有时候你没有权限改 IDE 配置或者就是懒得重启也有办法。最直接的是用 2.1 节提到的 Save console output to file路径填到项目下的 logs 目录连日志框架都不用改控制台输出会从第一行开始完整落盘。缺点是它只记录控制台实际收到的内容如果程序自己用了异步输出顺序上可能和文件里略有出入。另一个思路是从启动命令入手把标准输出和标准错误重定向到文件再用命令行实时跟随。在 Linux 或者 macOS 下大概是这样java -jar app.jar logs/stdout.log 21 tail -f logs/stdout.logWindows 下对应的写法是用 cmd 的重定向配合 PowerShell 的读取java -jar app.jar logs\stdout.log 21 powershell -Command Get-Content logs\stdout.log -Wait -Tail 100这套做法把查看这件事从 IDE 里搬到了终端好处是终端的滚动缓冲可以设得非常大而且完全不受 IDE 内存策略的影响。缺点也明显没法直接点日志里的类名和行号跳转调试体验会下降。所以我一般只在跑长任务、重任务的时候这么干日常开发还是老老实实待在 IDE 里。4. 排查速查改了不生效的七种情况4.1 逐条对照表这是我这些年攒下来的改了没用清单基本覆盖了九成以上的情况现象大概率原因处理办法改完完全没变化改的是安装目录下的文件实际读取的是用户配置目录用 Edit Custom Properties 入口重新建一份改完完全没变化修改后没有重启 IDE完整退出并重新启动不是关窗口值看起来生效了但日志还是丢该运行配置勾了 Override console cycle buffer size取消勾选或者把值一起改大只有某个项目有问题该项目用了独立的启动脚本绕过了 IDE 的运行配置检查脚本里的输出重定向和日志框架配置数字填了但感觉容量不对属性单位是 KB误按 MB 填写重新核对数量级10MB 要写 10240写了 disabled 后行为异常当前版本对这个值的解析不一致换成一个大数字比如 102400多个版本都装了改了一个没反应改的不是当前实际运行的那个版本的配置目录从 About 里确认版本号和安装来源再定位目录表格之外再补一个隐蔽的坑属性文件里不允许中文全角字符混在里面尤其是你从网页复制粘贴配置行的时候很容易把等号或者数字粘贴成全角。肉眼看着一模一样解析器就是认不出来。遇到怎么都不生效的情况把那一行删掉手敲一遍往往就好了。这个坑我踩过不止一次。4.2 缓冲开太大之后的新问题把缓冲从 1MB 调到 100MB解决了看不到前段日志的问题但引入了新的问题得提前有心理准备。首先是 IDE 的内存占用会上去尤其是同时开着好几个运行窗口的时候每个窗口都有自己的缓冲。其次是 IDE 在做全量索引、代码分析这些本来就吃内存的操作时可用的堆空间被压缩卡顿感会变明显。第三如果日志里有特别大的对象打印比如一个几 MB 的 JSON单行就能吃掉不少缓冲这种时候单纯加容量性价比很低。我个人的经验阈值是 50MB 左右。超过这个数就该换思路了——要么减少输出量把日志级别调高屏蔽掉那些没营养的框架 DEBUG要么改成写文件用命令行工具去看。把内存当日志仓库用从来都不是一个好选择。4.3 我常用的一套组合配置说一套我在实际项目里固定使用的配置组合你可以直接照搬。IDE 层面idea.properties 里设 10240也就是 10MB覆盖绝大多数调试场景遇到长任务单独在 Run 配置里勾 Save console output to file。项目层面logback 里同时挂 ConsoleAppender 和 RollingFileAppender滚动的三个参数按 50MB、7 天、3GB 来配。日志级别上业务代码用 INFO框架和第三方库统一压到 WARN只在需要时临时给某个包开 DEBUG。这套组合跑下来日常开发几乎不会再遇到日志去哪儿了的问题。真要回溯三天前的某次异常直接去 logs 目录按时间找文件就行比在控制台里翻靠谱得多。控制台的角色回归到它该有的样子一眼扫过去看有没有红字看完就翻篇。5. 几个只有天天看日志的人才会注意的细节5.1 重复行折叠与假丢日志IDEA 的控制台有个很实用的功能连续多行完全相同的输出会被折叠成一个带数字的提示左边有个小三角可以点开。这个功能在日志大量重复的时候非常友好但也制造了不少日志被覆盖的误报。判断方法很简单折叠的地方会明确显示重复的次数字面意思是还有 XX 行相同内容跟缓冲区溢出那种从中间断掉的表现完全不同。真丢了是找不到开头折叠是行都在只是被收起来了。另外还有一个容易误判的情况某些框架在控制台里输出回车符来做进度条刷新这种动态刷新的行在日志文件里会变成一长串覆盖的内容在控制台里看着则一直在变。如果你发现日志文件里有一堆奇怪的字符先去程序里搜一下有没有用回车符做进度提示的代码八成就是它。5.2 中文乱码与编码链路日志里的中文变成问号或者方块这个问题跟缓冲大小没关系但经常和它一起出现因为大家都是在日志不正常这个现象下把两件事混在一起排查。整条链路有三个编码点源码文件的编码、编译时的编码参数、日志输出时的编码。Maven 项目里可以在编译插件里显式指定源码和报告编码日志框架的 encoder 里也要写上 charset前面那份 logback 配置里的 UTF-8 就是干这个用的。这三个点只要有一个不对中文就会出问题表现可能是全是问号也可能是一半对一半错。在 Windows 上还要额外注意一点控制台默认代码页有时候和 UTF-8 不一致导致 IDE 里看着正常一旦用命令行重定向到文件就乱码。这种情况可以在启动参数里加上文件编码相关的设置或者干脆让日志框架统一用 UTF-8 输出从源头统一比事后猜编码要省事得多。5.3 团队协作里的配置约定idea.properties 是个人配置进不了版本库也不该进版本库。但日志框架的配置文件是项目资产应该提交到 resources 目录并且全组统一。这里有个常见的翻车点有人本地为了调试把某个包的日志级别改成了 DEBUG忘了改回去提交上去之后所有人的日志量暴涨控制台缓冲瞬间被打满于是又有人来问日志怎么又被覆盖了。所以项目里的日志级别最好集中在配置文件的一处管理别散落在代码里用编程方式改。还有一点值得提醒.idea 目录下有相当一部分文件是个人环境相关的比如运行配置里如果勾了 Save console output to file 并写了本机绝对路径这个文件提交上去之后别人拉下来会因为路径不存在而报错或者行为异常。团队里最好约定清楚哪些文件提交、哪些忽略运行配置这类东西要么不提交要么用相对路径。最后分享一个我自己用顺手的小技巧给日志的 pattern 里固定加上线程名和简化的类名也就是 %thread 和 %logger{36} 这两个占位符。日志丢不丢是一回事丢的时候能不能快速判断是哪个模块在疯狂输出是另一回事。有了这两个字段你一眼就能看出是某个定时任务在刷屏还是某个连接池在做健康检查。定位到输出源头之后压级别、加过滤条件这些动作才有地方落。多数时候把噪音降下去比把缓冲区调大要有效得多。
