解决idea 启动后CPU飙升的问题

解决idea 启动后CPU飙升的问题

CPU飙升是因为idea产生了某种疯狂消耗CPU资源,可以通过idea自带的监控来来观察到底是什么进程占用了CPU的资源
iead监控所在地
Iead监控
其实网上大部分讲的都是因为JIT(just in time,即时编译技术)导致CPU飙升,但是经过我的检测发现,JIT也仅仅是我的idea卡顿的一部分原因。

配置前:
不配置JIT参数前
配置后:
在这里插入图片描述
可以观测到idea CPU还是会飙升,但是JIT所占用的CPU大幅度下降,说明还是很有效果的。

# JIT 参数

# 设置用于编译的编译器线程数
-XX:CICompilerCount=2
# 开启分层编译
-XX:TieredStopAtLevel=1
# 控制最大数量嵌套调用内联
-XX:MaxInlineLevel=3
-XX:Tier4MinInvocationThreshold=100000
-XX:Tier4InvocationThreshold=110000
-XX:Tier4CompileThreshold=120000

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

因为我的idea是新装的,他的堆大小参数为:

-Xms128m
-Xmx2048m

然后查阅资料得知,当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

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

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

至于网上还有提出的插件,或者代码检查我们也可以去尝试一下,通过修改里面的配置结合idea自带的监控来快速准确定位问题,但是也告诉我们,要对症下药,有自带的工具去帮你,何乐而不为呢?

### 回答1: 在接口测试中,依赖登录状态的接口需要先进行登录操作,获取登录后的token或session等信息,然后将这些信息作为请求参数传递给需要测试的接口。测试时需要验证登录状态是否正确,以及接口返回的数据是否符合预期。同时,还需要测试登录状态失效后的接口返回情况,以保证系统的安全性和稳定性。 ### 回答2: 在接口测试中,当涉及到需要登录状态的接口时,需要特别注意测试。因为这些接口需要保证在正确的登录状态下才能正确地进行操作和返回结果。下面是一些应该考虑到的测试步骤: 1.确定登录状态对接口的影响 在测试依赖登录状态的接口之前,需要明确登录状态对接口的影响。为此,我们应该在测试计划中提供详细的用例。测试人员应该体面地覆盖所有目标结果,并特别注意测试通过不同用户角色的接口,以确保在不同用户角色的登录状态下接口行为的正确性。 2.独立测试登录接口 在测试依赖登录状态的接口之前,需要先独立测试登录接口。如果登录接口出现问题,那么依赖登录状态的接口肯定无法工作。在这种情况下,测试团队必须确保登录接口能够正常的执行和返回预期结果。 3.操纵缓存和Cookies 测试通过操纵缓存和Cookies模拟操作会话失效情况,从而测试依赖登录状态的接口。例如,通过删除或修改Cookies或缓存数据以模拟过期会话,以确保接口的行为和状态正确响应。同时,测试也可以操作在同一时间内的多个会话,以确保会话和管理的正确性。 4.模拟登录和注销场景 测试人员可以通过不同的方式模拟登录和注销场景。例如,测试可以通过模拟重复登录或同时存在多个登录会话的情况来测试接口的准确性,并且在随后的注销场景中,测试可以验证是否安全注销了会话,并且没有留下敏感信息在会话中。 5.模拟会话超时 在实际使用过程中,会话超时是常见的场景之一。测试人员需要模拟会话超时的场景,并且确认接口的响应是否正确。 总之,测试依赖于登录状态的接口是非常重要的。确保正确地测试会话管理,行为和状态会有助于提整个应用程序的质量,达到用户的期望。 ### 回答3: 在进行接口测试中,遇到依赖登录状态的接口,需要采取一些特殊的测试方法,以确保测试结果的准确性和全面性。以下是一些测试建议: 1. 准备测试数据 登录状态的接口测试需要有一定的测试数据,包括登录用户名和密码。测试数据可以通过手动创建,或者通过自动化测试工具创建。 2. 保持登录状态 在进行接口测试时,需要保持登录状态才能执行后续操作。可以使用手动方式登录,或者通过代码自动化登录,并将登录状态保存下来。 3. 测试正常登录和非法登录的情况 接口测试时需要测试正常登录和非法登录的情况,以确保系统能够正确处理这些情况。正常登录需要输入正确的用户名和密码,而非法登录则需要输入不存在的用户名或错误的密码。 4. 测试登录状态失效的情况 在接口测试中,需要模拟登录状态失效的情况,以确保系统能够正确处理这种情况。可以通过手动方式注销登录,或者在代码中设置登录状态失效。 5. 测试重复登录的情况 有些系统可能不允许用户重复登录,需要测试这种情况。可以通过手动方式和代码自动化方式测试。 6. 针对特定用户测试 如果是针对特定用户进行接口测试,需要使用特定用户的账号进行测试,确保测试结果具有代表性。 综上所述,接口测试中依赖登录状态的接口测试,需要考虑多种情况,依据不同情况采取不同的测试方法,这样才能保证测试结果的准确性和完整性。同时,可以通过自动化测试工具执行测试,提测试效率和一致性。
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值