解决问题的思路_云澜博客

作者：爱喝兽奶帝天荒 | 2024-08-14 22:30:21

踩

云澜博客

Java进程CPU 占用过高问题解决：

原因：	1.Java内存不够或溢出导致GC overhead问题，GC overhead导致的cpu 100%问题
	2.死循环问题，如常见的hashMap被多个线程并发使用导致的死循环；或者死循环。
	3.某些操作一直占用CPU：开发人员代码存在问题，例如写while循环条件判断bug导致死循环总结：首先，无限循环会调用CPU寄存器进行计数，这个操作会占用CPU资源。那么，如果线程一直处于死循环状态，CPU会不会切换线程呢？除非操作系统时间片到期，否则无限循环不会放弃占用的CPU资源，并且无限循环会继续向系统请求时间片，直到系统没有空闲时间做其他事情。
	4.sql索引未命中导致大表全表扫描
	5.系统有计算性任务，消耗CPU
	6.频繁的 GC；如果访问量很大，可能会导致频繁的GC甚至Full GC。当调用量大时，内存分配会非常快，以至于 GC 线程会不断执行，导致 CPU 飙升。
	7.序列化和反序列化。
	8.加密和解码。
	9.正则表达式。原因可能是Java正则表达式使用的引擎实现是NFA自动机，它会在字符匹配时进行回溯。
	10.线程上下文切换。有很多启动的线程，这些线程的状态在 Blocked（锁等待、IO等待等）和 Running 之间不断变化，当锁争用激烈时，这种情况很容易发生。一些线程不断执行非阻塞操作，例如while (true)语句。如果程序中计算时间较长，可以休眠线程。
	11.Young GC 本身就是 JVM 进行垃圾回收的操作，需要计算内存和调用寄存器，因此频繁的 Young GC 肯定会占用 CPU 资源。举例：for 循环从数据库中查询数据集合，然后再次封装新的数据集合。如果内存不够存储，JVM 会回收不再使用的数据。因此，如果需要的存储空间很大，可能会收到 CPU 使用率警报。
解决过程	1.检查线程数、JVM、系统负载等参数 2.用 jstack 打印堆栈信息，使用工具分析线程使用情况
解决过程	1.使用top命令，查看占用CPU的进程：top
	2.使用ps -ef \| grep java 命令，找出服务器的所有的Java进程： ps -ef \|grep java
	3.找出cpu耗用最厉害的进程pid
	4.找出具体占用cpu 利用率最厉害的线程号，top -h -p pid
	5.将获取到的线程号转换成16进制
	6.导出线程栈
	7.导出堆：jstat -gcutil 1706
	8.jvisualvm分析快照使用Java_home/bin/jvisualvm.exe,载入快照：文件---》载入---文件类型（dump）

注册中心Eureka:

eureka	eureka是Netflix开源的服务注册和发现的产品，目前已闭源，提供了完整的服务注册和发现。springcloud 的核心组件，需要手动搭建配置eureka server 服务器。
无效服务	Eureka只能通过任务定时剔除无效的服务。
自我保护	Eureka自我保护机制。如果出现大量的服务实例过期被剔除，则注册中心进入自我保护模式，注册表中信息不再被剔除，目的是提高eureka的可用性。默认情况下，统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期。
bug经历：	当时服务部署成功，在Eureka注册中心已经显示该服务已经注册成功，但是，前端请求经过网关再转发到该服务时，一直就没有反应，服务调用一直不成功。nginx转发，网关转发都在确认问题到底发生在哪里，几经折磨，在网关直接通过ip地址转发到上线的服务，快速的解决该问题。后续，复盘，应该Eureka的自我保护机制，导致的问题。在注册中心注册的服务是一个不可用的服务，但是，由于自我保护机制，Eureka Server没有将无效的服务剔除。
解决办法	后续的解决方法是，设置enableSelfPreservation=false关闭自我保护机制，把renewalPercentThreshold 比例降低，在Eureka Server端，如果出现无效的服务就会将该服务剔除。

加了唯一索引，依旧产生重复数据：

原因

如果唯一索引的字段中，出现了null值，则唯一性约束不会生效。

总结：创建唯一索引的字段，都不能允许为null，否则mysql的唯一性约束可能会失效。

现象：

1.当model_hash字段不为空时，不会产生重复的数据。

2.当model_hash字段为空时，会生成重复的数据。

两种删除

1.物理删除，即该记录被删除之后，后续通过sql语句查不出来。

2.逻辑删除，主要是通过update语句操作的。

总结：物理删除可以加唯一索引，逻辑删除无法加唯一索引

索引方案

方案1：正常就是0，每次删除都获取那条相同记录的最大删除状态，然后加1。

总结：由于每次删除时，delete_status都不一样，所以可以保证唯一性。

方案2：增加时间戳字段。把索引字段和时间戳字段同时做成唯一索引。

步骤：在添加数据时，timeStamp字段写入默认值1。然后一旦有逻辑删除操作，则自动往该字段写入时间戳。这样即使是同一条记录，逻辑删除多次，每次生成的时间戳也不一样，也能保证数据的唯一性。在那种极限并发的场景下，对同一条记录，两次不同的逻辑删除操作，产生了相同的时间戳。这时可以将时间戳精确到毫秒。

优点是：可以在不改变已有代码逻辑的基础上，通过增加新字段实现了数据的唯一性。

缺点是：在极限的情况下，可能还是会产生重复数据。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/980938