当前位置：首页 > news >正文

【优化】IntelliJ IDEA 优化 CPU过高的问题提高响应速度

news 2026/5/25 7:08:30

【优化】IntelliJ IDEA 优化 CPU过高的问题提高响应速度

解决idea 启动后CPU飙升的问题
CPU飙升是因为idea产生了某种疯狂消耗CPU资源，可以通过idea自带的监控来来观察到底是什么进程占用了CPU的资源

其实网上大部分讲的都是因为JIT（just in time,即时编译技术）导致CPU飙升，但是经过我的检测发现，JIT也仅仅是我的idea卡顿的一部分原因。配置前：

配置后：

2025年8月

# ========================= # 内存配置 # ========================= -Xms512m -Xmx4096m -XX:ReservedCodeCacheSize=1024m # ========================= # GC 优化 # ========================= -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:-OmitStackTraceInFastThrow # ========================= # 协程线程池优化 # 限制 kotlinx.coroutines 的 ForkJoinPool 并行线程数 # 避免 DefaultDispatcher-worker 占满 CPU # ========================= -Djava.util.concurrent.ForkJoinPool.common.parallelism=2 # ========================= # JIT 编译器优化 # 减少 JIT 编译器线程占用 CPU # ========================= -XX:CICompilerCount=2 -Dcompiler.process.use.jvm=true # ========================= # 禁用 JetBrains Fleet 内核 # Fleet 会在后台运行并占用大量 CPU # ========================= -Dide.fleet.launcher.disable=true # ========================= # 禁用 JetBrains AI 功能 # 如果不需要 AI 补全和 AI 聊天功能，建议关闭 # ========================= -Dai.features.enabled=false # ========================= # 关闭 Kotlin 协程调试模式 # 防止 kotlinx.coroutines.debug.internal 过高占用 # ========================= -Dkotlinx.coroutines.debug=off # ========================= # 其他保持不变 # ========================= -XX:+IgnoreUnrecognizedVMOptions -Dsun.io.useCanonCaches=false -Djdk.http.auth.tunneling.disabledSchemes="" -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -XX:ErrorFile=$USER_HOME/java_error_in_idea_%p.log -XX:HeapDumpPath=$USER_HOME/java_error_in_idea.hprof --add-opens=java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED --add-opens=java.base/jdk.internal.org.objectweb.asm.tree=ALL-UNNAMED

可以观测到idea CPU还是会飙升，但是JIT所占用的CPU大幅度下降，说明还是很有效果的。

后续又发现是因为不断地在进行GC导致CPU飙升，因为每次GC都会消耗99%的CPU资源，于是想着修改JVM参数来解决这个问题。

然后查阅资料得知，当Xms设置值比较小时，会频繁的触发GC，而GC又会出现STW的情况，所以idea一直GC，那你的idea也必然是一卡一卡的，同时大部分都推荐相同值，这是为什么呢？

这是为了避免在由于heap内存扩大或缩小导致应用停顿，降低延迟，同时避免每次垃圾回收完成后JVM 重新分配内存。

所以修改后的堆的大小为：

-Xms2048m
-Xmx2048m

然后又发现自己的GC收集器使用的是CMS，那么读过JVM这本书的都知道，CMS采用标记-清理的算法，标记出垃圾对象，清除垃圾对象。算法是基于老年代执行的，因为新生代产生无法接受该算法产生的碎片垃圾。他的缺点是：

无法清理浮动垃圾，并发收集会造成内存碎片过多
由于并发标记和并发清理阶段都是并发执行，所以会额外消耗CPU资源
基于此，我将垃圾收集器也替换为了G1，G1的优势是：

可控制回收垃圾的时间
和CMS一样采用标记-清理的算法，但是G1不会产生空间碎片（G1从整体来讲是基于标记-整理来实现垃圾回收
从局部来讲，又是把整个堆，切割为大小均匀的多个region，region与region之间采用标记-复制算法实现），这样就有效的使用了连续空间，不会导致连续空间不足提前造成GC的触发。

最终JVM参数：

-server -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=512M -XX:+AlwaysPreTouch -Xms2048m -Xmx2048m -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:AutoBoxCacheMax=20000 -ea -Dsun.io.useCanonCaches=false -Dsun.awt.keepWorkingSetOnMinimize=true -Djava.net.preferIPv4Stack=true -Djdk.http.auth.tunneling.disabledSchemes="" -Djsse.enablesSNIExtension=false -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -Dfile.encoding=UTF-8 # JIT 参数 # 设置用于编译的编译器线程数 -XX:CICompilerCount=2 # 开启分层编译 -XX:TieredStopAtLevel=1 # 控制最大数量嵌套调用内联 -XX:MaxInlineLevel=3 -XX:Tier4MinInvocationThreshold=100000 -XX:Tier4InvocationThreshold=110000 -XX:Tier4CompileThreshold=120000

分布式项目

减少内存

在设置项目的时候尽量不要将没有关系的项目放置在一个工程中，这样能够减少内存的使用。比如比较大的maven项目或者分布式项目都喜欢分成很多模块。但是，实际上自己只负责一个模块，可以根据自己的项目依赖只导入自己相关的module。

可以点击右键，load/unloan modules，只导入自己需要的模块。

【编译器自带】适当关闭idea的Inspections的检查或者开发时完全关闭Inspections的检查，等开发完后在开启检查。可以全部关闭，idea右下角有一个人头标志，可以点击，调准idea检查级别~

如果以上操作还是不能解决CPU过高的话，还可以打开

1、打开idea设置 File–>Settings–> Build,Execution,Deployment --> Compiler
2、调整 Shared build process heap size(Mbytes) 大小，默认值700，可修改至 2048（或者自定义数值）

查看全文

http://www.zskr.cn/news/1375801.html