两天没解决的问题chatgpt用了5秒搞定隐藏bug

chatgpt 5秒解决bug chatgpt 解决bug 2023-05-15 08:05:40 803人浏览薄情痞子

Python 官方文档：入门教程 => 点击学习

摘要

目录前言隐藏的“间谍”code验证第一位”间谍“借助GPT“侦探柯南”找出"真凶"ai已来

前言

一个说难不难，说简单竟看不出来是哪里问题的一个bug。是的可能自己能力和经验尚浅无法识别，下面你们能否用火眼金睛一眼让bug原形毕露

（这个问题是忽然暴露出来的，无任何征兆，没人改动过，生产上运行了很长时间，故很奇怪，所以这个间谍看来很会隐藏）

隐藏的“间谍”

下面先来看代码（伪代码）

code



public static void testCount(CountDownLatch countDownLatch, List<String> all) {
    for (int i = 0; i < 2; i++) {
        int finalI = i;
        ThreadPoolFactory.getGeneral().execute(() -> {
            try {
                List<String> countList = new ArrayList<>();
                //这里之所以用for循环，是因为查询业务需要0和1两个状态去查询
                if (finalI == 0) {
                //这里其实是查询数据库的mapper操作，为了方便演示
                    countList.add("1");
                    countList.add("2");
                    countList.add("3");
                } else {
                //这里其实是查询数据库的mapper操作，为了方便演示
                    countList.add("5");
                    countList.add("6");
                    countList.add("7");
                    countList.add("8");
                }
                if (countList != null) {
                    all.addAll(countList);
                }
            } catch (Exception ex) {
                ex.printStackTrace();
            } finally {
                countDownLatch.countDown();
            }
        });
    }
}
//线程池类
public class ThreadPoolFactory {
    private static final Logger logger = LoggerFactory.getLogger(ThreadPoolFactory.class);
    private static final ThreadFactory GENERAL_THREAD_FACTORY = new ThreadFactoryBuilder().setNameFORMat("general-pool-%d").build();
    
    private static final ExecutorService GENERAL = new ThreadPoolExecutor(5, 10,
            30L, TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<>(4096), GENERAL_THREAD_FACTORY, new ThreadPoolExecutor.AbortPolicy());
    public static ExecutorService getGeneral() {
        return GENERAL;
    }
}
//main方法测试
public static void main(String[] args) throws Exception {
    List<String> all = new ArrayList<>();
    CountDownLatch countDownLatch = new CountDownLatch(2);
    testCount(countDownLatch,all);
    countDownLatch.await(10, TimeUnit.SECONDS);
    System.out.println(all);
}

对于上面CountDownLatch不了解的的可以看下我历史的文章：干货！CountDownLatch的使用场景

看到这里不知道你们能否看出端倪，先说问题结果吧，最后的这个all集合为空，生产上的接口也是同样的问题，我上面的代码是和生产上的1:1复制的伪代码。

我先说下我的排查思路：

1、线程池问题，我认为是线程没有被及时的回收，时间太长，并发数过高，导致线程不够用，第一想到的是便是线程数需要增加

2、数据库数据过多，导致查询比以前慢出一个量级，最后队列阻塞，拖垮线程（这个概率比较低，因为数据库查询很快返回，并没有需要优化的慢sql）

3、怀疑是这个循环造成的，比如某种机制少循环或者不循环，去掉for循环依然没解决问题

验证第一位”间谍“

首先扩大核心线程数和最大线程数，将这俩参数扩大为10和20

private static final ExecutorService GENERAL = new ThreadPoolExecutor(10, 20,
            30L, TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<>(4096), GENERAL_THREAD_FACTORY, new ThreadPoolExecutor.AbortPolicy());

扩大之后，放上去能查出数据了，感觉解决了这个大问题

那句话怎么说来着，真相往往不是那么的容易发现，最先抓到的都是小鱼小虾，果不其然，运行了一周左右，同样的问题又出现了，感觉这就是一水缸，你把水缸变大，终有蓄满的一天。我们都知道，线程池可不是越大越好。

那么真相究竟是什呢，看到这里的小伙伴如果你已经有了答案，可以先去评论区评论，不要看下面的答案。