bigfish的网络博客 - 排查

一个正则表达式导致 CPU 高的问题排查过程

bigfish — Mon, 05 Oct 2020 10:00:00 +0800

这篇文章记录一个正则表达是导致 CPU 高的问题排查。由于无法直接使用线上的代码测试，所以我自己把代码整理了下来，具体代码如下：

public class AppMain {
	public static void main(String[] args) throws InterruptedException {
		final String regex="^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$";
		final String email="blog.laofu.online.fuweilao@vip.qq.com#";
		for (int i = 0; i < 1000000; i++) {
			Matcher matcher = RegexUtils.matcher(regex, email);
			matcher.find();
			Thread.sleep(10);
//			matcher.group();
		}
	}
}

当运行程序的时候，我们可以看到 java 的进程占用了 CPU 了 82.1%,由于我使用的服务器是 1核+2G, 所以 load avg 占用也很高。

简述 G1 垃圾回收器和 OOM 问题的排查

bigfish — Sat, 12 Sep 2020 10:00:00 +0800

最近又碰到的 oom 的问题，一直在尝试定位中，由于现实使用的 G1 的垃圾回收器。所以今天打算线上的排查历程和方案查询出来。

jvm 常用参数

-Xmx1024m 最大堆内存
-Xms1024m 最小堆内存
-Xss256k  设置栈的大小。栈都是每个线程独有一个，所有一般都是几百k的大小。
-XX:MetaspaceSize=128m  元空间的大小
-XX:MaxMetaspaceSize=256m  最大元空间大小
-XX:MaxGCPauseMillis=200 设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值
-XX:+UseG1GC 使用 G1 垃圾回收器
-XX:-OmitStackTraceInFastThrow 当一些异常在代码里某个特定位置被抛出很多次的话，HotSpot Server Compiler（C2）会用fast throw来优化这个抛出异常的地方。
-XX:MinHeapFreeRatio=30
-XX:MaxHeapFreeRatio=50
-XX:MaxDirectMemorySize=100M 直接内存大小
-XX:+PrintGCDetails 打印 GC 详细信息
-XX:+DisableExplicitGC 禁止显示GC

newFixedThreadPool 线程池导致线程泄漏

bigfish — Thu, 21 Feb 2019 10:00:00 +0800

现象问题

最近看到线上的项目线程数过大的报警，开始还是不知道什么原因，因为很多项目都使用同样的线程池管理代码，认为那个项目是偶然的因素造成的，后来经过分析，发现线程数每天都在增加。其他的项目由于发布导致线程会从零开始计算，所以没有那么快达到报警值。触发报警的代码大概如下：

boolean start=true;
public void doSomeThing(){
    ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
    Thread thread = new Thread(() -> {
        while (start) {
            try {
                if(.//判断能否执行){
                    Thread.sleep(100);
                    return;
                }
                executorService.execute(() -> {
                    try {
                        //....your code
                    } catch (Exception e) {

                    } finally {
                    
                    }
                });
            } catch (Exception e) {
            }
        }
    });
    thread.start();
}

public int getMaxThreadCount(){
    return ....;
}
public void stop(){
    this.start=false;
}

上面的代码存在两个问题：

start是个主线程的变量，在主线程修改值，子线程的while循环不会停止

上述代码能够停止，因为在内部调用`Thread.sleep方法，导致线程内的变量刷新
newFixedThreadPool 线程池没有调用shutdown方法，导致线程不会被回收。

改正方法：

start 设置成线程共享变量volatile类型
在最后调用停止的时候，让线程池进行回收

修改后代码如下：


volatile boolean start=true;
ExecutorService executorService;
Thread thread ;
public void doSomeThing(){
    executorService = Executors.newFixedThreadPool(nThreads);
    thread = new Thread(() -> {
        while (start) {
            try {
                 if(.//判断能否执行){
                    Thread.sleep(100);
                    return;
                }
                executorService.execute(() -> {
                    try {
                        //....your code
                    } catch (Exception e) {

                    } finally {
                    
                    }
                });
            } catch (Exception e) {
            }
        }
    });
    thread.start();
}

public int getMaxThreadCount(){
    return ....;
}
public void stop(){
    this.start=false;
    if (executorService != null) {
        executorService.shutdown();
        executorService.awaitTermination(MaxConcurrency() * 3, TimeUnit.SECONDS);
        for (int i = 0; i < 10 && !executorService.isTerminated(); i++) {
            Thread.sleep(1000);
        }
    }
    if (thread != null && thread.isAlive()) {
        thread.interrupt();
        thread.join(2000);
    }
}

最后的疑问

线程池在最后不使用后，为什么线程没有被释放？GC为什么没有把线程池对象回收？是怎么做到的？

目前还没有找到问题的答案，等找到后回来更新。

服务器 CPU 居高不下：一次 Dump 排查历程

bigfish — Wed, 27 Sep 2017 10:00:00 +0800

基本的概述

在一个服务器的集群上面，服务器的CPU长时间居高不下，响应的时间也一直很慢，即使扩容了服务器CPU的下降效果也不是很明显。

对于CPU过高的原因，可以总结到以下原因：

太多的循环或者死循环
加载了过多的数据，导致产生了很多的大对象
产生了过多的对象，GC回收过于频繁（如：字符串拼接）

对于上面的情况，难点不是优化代码，难点在于定位到问题的所在，下面我们就用Dump抓包的方式来定位到问题的所在。介绍这个内容之前，我们要先回顾下.Net中垃圾回收的基础知识和一个工具的准备。

基础知识

垃圾回收触发条件

代码显示调用System.GC的静态方法
windows报告低内存情况
CLR正在卸载AppDoamin
CLR正在关闭

大对象垃圾回收

CLR将对象分为大对象和小对象，认为大于85000字节或者更大的字节是大对象，CLR用不同的方式来对待大对象和小对象：

大对象不是在小对象的地址空间分配，而是在进程地址空间和其他地方分配
GC不会压缩大对象，在内存中移动他们的代价过高，但这样会造成地址空间的碎片化，以至于会抛出OutOfMemeryException 异常。
大对象总是在第二代回收。

工具准备

下载windbg文件
相关DLL准备clr.dll和sos.dll，(都在对应.Net版本安装目录下面，我的安装目录在C:\Windows\Microsoft.NET\Framework64\v4.0.30319)
一个cpu运行的较高的时期的DUMP文件（下面会说如何获取）
准备测试代码，此处为了演示方便，简单了写了一个有潜在问题的代码：

public  class Common
{
    public static List<string> GetList()
    {
        var list=new List<string>();
        for (int i = 0; i < 10000; i++)
        {
            list.Add(i.ToString());
        }
        return list;
    }


    public static string GetString(List<string> list)
    {
        var str = "";
        foreach (var l in list)
        {
            str += string.Format("'{0}',", l);
        }
        if (str.Length > 0)
        {
            str.Remove(str.Length - 1);
        }
        return str;
    }
}

我们知道在字符串的拼接的时候，每一个字符串都是一个对象，拼接后又产生了一个新对象，所以在GetString这个方法中会有大量的GC操作，下面我们就调用下这个代码，看下CPU的情况，为了模拟并发情况，我们开多个标签，每个标签每1s秒中刷新一次。

抓取Dump

在任务管理器中选择应用程序池对应的w3wp.exe，右击-->创建转储文件。创建完成后，会提示出指定的路径

根据上面的步骤，我们准备我们分析的文件如下：

分析Dump

打开windbg，加载对应的dump文件
配置Sysmbol，添加"cachec:\mysymbol;srvhttp://msdl.microsoft.com/download/symbols"

load sos.dll和clr.dll，命令如下：

.load D:\windbg\sos.dll 
.load D:\windbg\clr.dll

运行命令!threadpool 显示有关托管线程池的信息，其它一些SOS 调试扩展命令.
运行!runaway 查询cpu占用时长比较长的几个线程Id
运行~22s (进入线程查看),kb(查看对应的调用)
运行~* kb 查看所有线程的堆栈调用
在上面搜索GC和大对象出现的线程（ctrl+f搜索：GarbageCollectGeneration和allocate_large_object ）
可以看到定位触发GC的线程是31号线程
运行命令~31s 进入31线程，再运行!clrstack查看堆栈调用，最终可以定位到出问题的代码，是由于字符串的拼接导致大量的对象产生，从而触发了GC。