线上问题定位指南与排查

写在文章前的话

由于小组内有个系统最近因线上卡顿，临时重启服务器解决，需要找到根本原因并汇报给领导，开启下面的分析之旅。但本人这方面经验欠缺，故留点笔记

线上问题描述

1. 内存溢出
   
2. 并发事务导致插入查询被中断
   
   

问题分析

内存溢出

1. 添加JVM 参数: -XX:+HeapDumpOnOutOfMemoryError，memory 溢出时候能自动生成heap dump文件（以hprof结尾的文件）
2. 用mat工具分析heap dump文件
   2.1 导入hprof文件后，mat会找到内存泄露的可疑点，点击详情可以查看
   
   2.2 详情里可以看出当时内存中对象的分布，以及可疑代码的定位
   
   （1）Shallow Size：对象本身占据的内存的大小，不包含其引用的对象
   （2）Retained Size：当前对象大小+当前对象可直接或间接引用到的对象的大小总和
   
   2.3 通过线程堆栈信息(上图Thread stack)可以定位到业务代码
   （1）最终定位是因为判断条件不严有脱库风险（业务代码不便展示）

通过GC日志分析

1. 添加-verbose.gc开关可显示GC的操作内容，并记录到gc.log日志中（重启后会重新记录）
2. 将gc.log日志压缩成zip，然后导入在线分析工具：http://gceasy.io
   2.1 对内容的说明博客：https://blog.csdn.net/CoderBruis/article/details/101234738
   

并发事务

1. 插入操作需要使用自增锁
   1.1 和自增锁相关的一个参数为innodb_autoinc_lock_mode:0,1,2
   （1） 0：traditonal （每次都会产生表锁）
   （2） 1：consecutive （会产生一个轻量锁，simple insert会获得批量的锁，保证连续插入）
   （3） 2：interleaved （不会锁表，来一个处理一个，并发最高）

2. 对于不存在的记录 并且在RR级别下，delete加锁类型为gap lock

   T1	T2
   beigin	beigin
   DELETE FROM lck_primarkey WHERE val =3 ;
   	DELETE FROM lck_primarkey WHERE val =3 ;//生效
   INSERT INTO lck_primarkey(val,status) VALUE(3,1);//等待
   	INSERT INTO lck_primarkey(val,status) VALUE(3,1);//死锁
   commit	commit

   2.1 gap lock之间是兼容的，所以两个事务都能成功执行delete（gap范围是索引val列(2,4)的范围）
   2.2 insert时，其加锁过程为先在插入间隙上获取插入意向锁，插入数据后再获取插入行上的排它锁

事务回滚后自增主键ID不会回滚

1. 插入回滚前的数据
   
2. 回滚数据

SET autocommit = 0;
BEGIN;
INSERT INTO lck_primarkey(val,`status`) VALUE(8,1);
ROLLBACK;

3. 插入数据
   INSERT INTO lck_primarkey(val,status) VALUE(8,1);