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

 更新时间:2023年04月10日 17:29:52   作者:苏世_  
这篇文章主要为大家描述了我用了两天没解决的问题chatgpt用了5秒搞定的全程介绍,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

前言

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

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

隐藏的“间谍”

下面先来看代码(伪代码)

code

/**
 * 两个从数据库查询的耗时任务
 * @param countDownLatch
 * @param all
 */
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();
    /**
     * corePoolSize:核心线程池大小
     * maximumPoolSize:最大线程池大小
     * keepAliveTime:线程最大空闲时间
     * unit:时间单位
     * workQueue:线程等待队列  四种队列 1.ArrayBlockingQueue:有界队列,2.SynchronousQueue:同步队列,3.LinkedBlockingQueue:无界队列,4.DelayQueue:延时阻塞队列
     * threadFactory:线程创建工厂
     * handler:拒绝策略 四种策略 1.ThreadPoolExecutor.AbortPolicy():2.ThreadPoolExecutor.CallerRunsPolicy():3.ThreadPoolExecutor.DiscardOldestPolicy():4.ThreadPoolExecutor.DiscardPolicy()
     */
    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());

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

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

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

借助GPT“侦探柯南”

chatgpt这里我就不多说了,这个东西如果现在还不了解的,那我就。。。就只能求求你赶紧去了解下吧

我把生产上的代码完整的贴上去,他是这样回答的

不得不说,一语中的,仅5秒就把我们所能想到和不能想到的都回答出来了

  • 很显然,第二点,第三点我们基本上验证通过了
  • 那就是第一点了,其实我们早就应该想到这一点的,多线程环境下,线程安全问题是首位的!!!

找出"真凶"

使用synchronized关键字解决线程安全

使用synchronized关键字来同步访问all列表,即在多个线程访问all列表时,使用同一个锁来保证线程安全,避免出现数据不一致的问题。这样就解决了多个线程可能会同时访问并修改数据,导致数据丢失或损坏的问题。

聪明的你有没有找出“真凶”呢???

还记得我们加大线程数来解决问题吗,我又问了一个问题

扩大线程池的参数可能会提高程序的并发处理能力,但并不能从根本上解决问题。如果是由于数据同步问题导致的线程池查不到数据,那么扩大线程池只是把问题暂时推迟了而已。此外,扩大线程池的核心线程池数量也会占用更多的系统资源

AI已来,未来已来

再啰嗦一句,AI的强大这里就不再强调了 ,接下来我会持续利用GPT输出很多干货和其他AI生态的东西,都收在下方的AI专栏里,一起学习,一起成长,用一句话作为结尾吧: 将来淘汰你的不是AI,而是不会用AI的人

以上就是两天没解决的问题chatgpt用了5秒搞定的详细内容,更多关于chatgpt 5秒解决问题的资料请关注脚本之家其它相关文章!

相关文章

  • Java包机制及javadoc详解

    Java包机制及javadoc详解

    为了更好地组织类,Java提供了包机制,用于区别类名的命名空间,一般利用公司域名倒置作为包名,这篇文章主要介绍了Java包机制以及javadoc,需要的朋友可以参考下
    2022-10-10
  • MyBatis加解密插件的示例详解

    MyBatis加解密插件的示例详解

    本文介绍了使用 MyBatis 插件实现数据库字段加解密的探索过程,实际开发过程中需要注意的细节比较多,整个流程下来我对 MyBatis 的理解也加深了,对MyBatis加解密插件感兴趣的朋友跟随小编一起看看吧
    2022-08-08
  • redis做服务间通信工具的项目示例

    redis做服务间通信工具的项目示例

    Redis是一种高效的服务间通信工具,它以键值对的形式存储数据,并支持多种数据类型和丰富的操作,本文主要介绍了redis做服务间通信工具的项目示例,感兴趣的可以了解一下
    2023-08-08
  • Java JSON处理库之Gson的用法详解

    Java JSON处理库之Gson的用法详解

    Gson是Google开发的一款Java JSON处理库,旨在简化Java开发人员操作JSON数据的过程,本文就来和大家简单聊聊Gson的原理与具体使用吧
    2023-05-05
  • 关于RestTemplate中的Get请求

    关于RestTemplate中的Get请求

    这篇文章主要介绍了关于RestTemplate中的Get请求,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-07-07
  • SpringBoot+Eureka实现微服务负载均衡的示例代码

    SpringBoot+Eureka实现微服务负载均衡的示例代码

    这篇文章主要介绍了SpringBoot+Eureka实现微服务负载均衡的示例代码,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2019-11-11
  • SpringBoot 整合RabbitMq 自定义消息监听容器来实现消息批量处理

    SpringBoot 整合RabbitMq 自定义消息监听容器来实现消息批量处理

    Spring Boot中提供了默认的监听器容器,但是有时候我们需要自定义监听器容器,来满足一些特殊的需求,比如批量获取数据,这篇文章主要介绍了SpringBoot 整合RabbitMq 自定义消息监听容器来实现消息批量处理,需要的朋友可以参考下
    2023-04-04
  • Java使用FileReader读取文件详解

    Java使用FileReader读取文件详解

    本文将为大家介绍FileReader类的基本用法,包括如何创建FileReader对象,如何读取文件,以及如何关闭流,感兴趣的小伙伴可以跟随小编一起了解一下
    2023-09-09
  • Java中Map集合的常用方法(非常详细!)

    Java中Map集合的常用方法(非常详细!)

    Java中的Map是一种键值对存储的数据结构,它提供了快速查找和访问数据的能力,下面这篇文章主要给大家介绍了关于Java中Map集合的常用方法,需要的朋友可以参考下
    2024-01-01
  • Spring Security如何在Servlet中执行

    Spring Security如何在Servlet中执行

    这篇文章主要介绍了Spring Security如何在Servlet中执行,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2020-04-04

最新评论