这里记录一下
查看了电脑的运行状态
idea一直占用高的cpu资源
于是加内如内存可以解决：
-Xmx4096m
简单来说：Java程序（包括IDEA）的内存管理机制和操作系统的内存调度，共同决定了"加内存"能直接"降CPU"。
具体原因可以拆解为以下三个核心层面：
1. 垃圾回收（GC）的"清理成本"大幅降低（最核心原因）
IDEA是用Java写的，它的内存由JVM（Java虚拟机）自动管理。当内存不足时，JVM会频繁触发垃圾回收（GC）来腾出空间。
- 内存小时 ：堆内存很快被占满，JVM不得不每秒甚至每几毫秒就执行一次GC。而GC尤其是"Full GC"（全局垃圾回收），会暂停整个程序，并大量消耗CPU资源来扫描、标记和清理对象。
- 内存增大后：堆内存变大了，对象存活的时间更长，GC触发的频率大大降低。CPU从频繁的"打扫卫生"中解放出来，自然占用率就下降了。
2. 避免了"反复重新计算"的无效消耗
IDEA为了让你能秒级跳转和提示，会把代码结构、依赖关系、索引信息缓存到内存里。
- 内存小时 ：内存装不下所有缓存，JVM会强行回收掉一部分缓存数据。当你要用到时，IDEA发现缓存没了，就必须重新消耗CPU去解析代码、扫描文件来生成这些数据。
- 内存增大后：常用的索引和缓存都能稳稳地待在内存里，IDEA直接拿现成的数据用，省去了大量重复计算，CPU占用自然下来了。
3. 操作系统层面的"内存交换（Swap）"被遏制（系统全局卡顿的关键）
你提供的任务管理器显示内存总占用已经高达86%，这时候操作系统（Windows）已经处于内存高压状态。
- 发生交换时 ：物理内存不够时，系统会把一部分内存数据强行挪到速度极慢的硬盘（SSD/机械盘）上充当"虚拟内存"。当IDEA需要这些数据时，CPU就必须等待硬盘把数据传回来。
- 为什么显得CPU高：在这种等待过程中，CPU并没有"空闲"，而是处于"高占用但低进展"的忙等状态（内核态开销）。任务管理器显示的CPU高占用，其实有很多是在"指挥硬盘搬运数据"。
- 增大内存后 ：IDEA不再依赖硬盘做虚拟内存，所有数据在内存条里快速读写。CPU不再需要花大量时间去"催"硬盘，虽然CPU频率可能没变，但有效计算吞吐量大幅提升，卡顿感消失。
打个通俗的比方：
- 内存小（你的现状） ：就像在一张极小的桌子上写代码，东西放不下就得频繁往柜子（硬盘）里搬（Swap），搬来搬去累得满头大汗（CPU高），还得时不时停下收拾桌子（GC）。
- 内存大（优化后） ：换了一张超大的会议桌，所有资料摊开在桌面随手拿，不需要频繁收拾，也不需要来回跑柜子搬资料，自然省力（CPU低）且效率高。
1. -Xms（初始堆内存）------ 相当于"起跑线的位置"
- 意思 ：
Xms代表 JVM 刚启动时，一次性向操作系统申请占用的内存大小（也就是"初始内存池"）。 - 为什么设得小（128m）会卡 ：就像你打车，只付了起步价的钱，车就只能跑 128 米。当 IDEA 需要加载更多代码时，发现"油不够"了，JVM 就得临时向操作系统喊话："再给我点内存！"（这叫扩容 ）。这个过程涉及系统调用，非常耗时，而且会导致 CPU 短暂飙升。如果项目很大，JVM 会"一点一点"地申请扩容（128m -> 256m -> 512m...），整个过程卡顿感非常明显。
- 为什么调大（512m 或 1024m）更好 ：相当于你一开始就包了一辆大车。IDEA 启动时直接把 1GB 内存攥在手里，无论后续加载多少类库、索引，内存都够用。这就省去了反复"申请扩容"的开销，启动速度和前几分钟的流畅度会有明显提升（放心，这 1GB 不会浪费，IDEA 会自己管理着用）。
2. -XX:CICompilerCount（编译器线程数）------ 相当于"厨房的厨师数量"
- 意思 ：在 Java 里，代码是先从磁盘读进内存（字节码），再实时翻译成 CPU 能懂的机器码（这叫 JIT 即时编译）。这个参数指定了**同时有几个"翻译官"（线程）**在做这件事。
- 为什么设为 2 比较保守 ：你的 CPU 是 4 核 8 线程（逻辑核心有 8 个）。
CICompilerCount=2意味着，不管 CPU 多闲，IDEA 后台做代码编译优化时，最多只派 2 个厨师进厨房干活。这虽然省电、不易发热，但遇到复杂方法或大量类加载时，编译速度慢，代码跑起来热不起来，你会感觉 IDEA 的代码提示和响应变"肉"。 - 为什么改为 4 更合适 ：改成 4 意味着允许同时有 4 个"翻译官"并行工作。对于你 4 核物理核心的 CPU，设置为 4 能充分利用多核优势 ，让 JIT 编译速度翻倍。这样 IDEA 能更快地把你的代码编译成高效的机器码，运行时的响应延迟会更低。
- 注：虽然你有 8 个逻辑线程，但物理核心只有 4 个，把编译线程设为 4 刚好占满物理核心，既不会导致 CPU 过热降频（不像设成 8 那样极端），也能榨干 CPU 性能，是目前的"甜点"设置。
总结一下这两个参数的配合效果：
-Xms解决的是"内存不够用时的抢资源卡顿"（解决内存申请的开销）。-XX:CICompilerCount解决的是"代码翻译速度慢的算力卡顿"（解决 CPU 并发利用不充分的短板）。
另外：
是在idea.vmoptions这个文件里修改的