前言

这篇来讲解线上环境遇到问题，并如何解决，大概从内存，cpu，无响应、以及多线程和最优多线程性能问题来解决

前言

一、内存泄漏和内存溢出区别以及怎么优化

1.1、定义

内存泄漏：是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。
内存溢出：申请内存前，系统已经不能再分配出你所需要的空间，保OOM错误。

1.2、内存泄漏可以分为4类

常发性内存泄漏：发生内存泄漏的代码，每次被执行的时候都会导致一块内存泄漏。
偶发性内存泄漏：发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。
一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。
隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。

1.3、内存溢出可能情况

检查对数据库查询中，是否有一次获得全部数据的查询。
检查代码中是否有死循环或递归调用。
检查是否有大循环重复产生新对象实体。
检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

1.4、内存溢出解决办法

修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误。
对代码进行走查和分析，找出可能发生内存溢出的位置。
使用内存查看工具动态查看内存使用情况

二、生产服务器CPU突然利用率高

遇到原因

程序计算比较密集：任务调度和业务逻辑拆分，任务调度底层死循环
程序死循环
程序逻请求堵塞
IO读写太高
设置网关、过滤、保证接口幂等性问题
被攻击，高并发。安装服务器监听工具，设置提醒

linux排查

先找到Java的进程号

top -c 查看CPU使用率高的进程的PID

找到里面是哪个线程占用率最高

top -H -p <pid> 查看该进程所有线程信息，找到占用率最高的那个

得到线程号的16进制

printf "%x\n" <pid>

分析dump查找问题代码片

可以用 jstack <pid> | grep -A <tid> 来实时获取内存中该线程代码片，这里<tid>是第3步中得到的16进制的id

分析dump文件
启动jvisualvm，并查看目标java进程信息，然后选择Sampler -> CPU -> Thread CPU Time

三、应用无响应如何处理

服务器没有及时线程池处理请求：走服务熔断，降级返回友好提示，代码将低耗时的代码采用异步（MQ、多线程）执行

四、多线程访问接口注意哪些事项

当多线程访问一个接口，有可能遇到线程安全。此时应使用lock锁和sys锁
如果接口耗时久，可以将耗时代码改成异步处理（MQ，多线程）
接口幂等性问题：

如果接口是insert，根据全局ID做唯一约束
如果update情况，根据版本号解决防止ABA

安全相关防护，防止攻击

五、如何最优提高多线程性能问题

使用线程池复用机制，不建议单独创建线程，从而提高多线程效率
建议使用乐观锁CAS，自旋，不建议使用悲观锁（乐观锁：消耗cpu，不阻塞，悲观锁：有阻塞）
使用sys锁时，尽量降低锁的持有时间，使用偏向锁和轻量锁，否则变为重量级锁情况，效率低（偏向锁–>轻量锁–>短暂自旋–>重量级锁阻塞）
使用锁的采用分段锁，减少锁的粒度
最好使用多核服务器，避免频繁切换上下文

六、文件过大

分析

查看储存大小

df -h

使用这个发现不太明显知道那个目录下文件过大

linux 怎么定位那个目录文件最大

du -ha /path/to/directory | grep -v "/$" | sort -rh | head -n 5

du -ha /path/to/directory：这个命令将给出目录 /path/to/directory 中所有文件和子目录的大小，-h 参数表示以人类可读的格式显示文件大小，-a 参数表示列出所有文件和子目录。
grep -v “/$”：这个命令将删除它的输出中所有文件夹，只保留文件。
sort -rh：这个命令将输出按照文件大小逆序排序（从大到小）。
head -n 5：限制这个命令的输出只返回文件大小最大的前 5 个文件。
您可以将/path/to/directory替换为您希望查找的目录路径。执行命令后，它将输出目录中最大的文件的路径和大小。

到这一步发现三个文件过大，那就是程序日志、/var/log/journal/ 和mysql binlog日志文件过大

如果 /var/log/journal/ 文件夹变得过大，可能是由于日志不断累积导致的。在这种情况下，您可以通过一些方法来解决问题：

删减不必要的日志文件：使用 journalctl 命令来检查和删除一些不必要的日志文件，可以使用 --vacuum-size 参数来指定愿意释放的磁盘空间，例如 journalctl --vacuum-size=100M 表示释放100MB的磁盘空间。

调整 journald 的日志最大大小：通过修改 journald.conf 文件来调整日志的最大大小限制，可以使用命令 systemctl edit systemd-journald.service 在编辑器中打开配置文件。在配置文件中添加以下配置：

[Journal]
SystemMaxUse=50M
这表示 journald 系统最多可以使用50MB空间来存储日志。修改保存并重启 journald，使用 systemctl restart systemd-journald.service 命令即可。

调整日志的过期时间：可以通过修改日志最大存储时间来解决问题，配置项为 MaxRetentionSec=。例如若要限制日志的最大存储时间为一个月，可以使用如下配置：

[Journal]
MaxRetentionSec=1month
完成配置后，保存修改并重启 journald 服务。

MySQL 的二进制日志（binary log）包含了对 MySQL 数据库所有写操作的记录。因此，二进制日志对于数据恢复和复制是非常重要的。但是，如果不进行定期清理，二进制日志可能会占用磁盘空间并影响性能。以下是清理 MySQL 二进制日志的步骤：

查询当前的 binlog 日志文件：

SHOW BINARY LOGS;
确定要保留的 binlog 日志文件。通常，您需要保留最近的几个 binlog 日志文件。例如，如果要保留最新的 3 个日志文件，则可以使用以下命令：

PURGE BINARY LOGS TO 'mysql-bin.000007';
以上命令将在删除 mysql-bin.000007 日志文件及其之前的所有日志文件。假设 mysql-bin.000007 是当前日志文件，那么这个命令将清除日志文件 mysql-bin.000001 到 mysql-bin.000006。

使用以下命令可以清除所有旧的 binlog 日志：

PURGE BINARY LOGS BEFORE NOW();
以上命令将删除在当前日志文件之前的所有 binlog 日志文件。

注意：在清理 binlog 日志之前，建议使用 mysqlbinlog 工具备份所有的二进制日志文件，以便在需要时进行数据恢复。此外，建议定期备份数据库以保障数据安全。

解决

最后分别处理三个日志

服务器日志

直接使用rm 删除

/var/log/journal/

查看前几名最大文件
删除命令 journalctl --vacuum-size=100M

mysql binlog日志

SHOW BINARY LOGS;
PURGE BINARY LOGS TO 'binlog.000070'; -- 该名字是删除该名字之前的日志