私は問題を解決するのに 2 日を費やしましたが、chatgpt はそれを完了するのに 5 秒かかりました

序文

1つは言うのが難しいことではありませんが、どこに問題があるのかわからないバグであることは簡単に言えます. はい、私の能力不足や経験不足で見分けがつかないかもしれませんが、次にバグの正体が一目でわかりますか？

(この問題は突然露呈し、何の症状もなく、誰も変更しておらず、長い間本番環境で実行されていたため、非常に奇妙で、このスパイは隠れるのが非常に上手なようです)

隠れた「スパイ」

最初にコードを見てみましょう（疑似コード）

コード


/**
 * 两个从数据库查询的耗时任务
 * @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 の使用シナリオ

これを見て、手がかりが見えるかどうかわかりません. まず問題の結果について話しましょう. 最後のすべてのセットは空であり、本番のインターフェイスも同じ問題です. 上記のコードは疑似コピーです.本番環境の 1:1 コピーのコード。

まず、私の調査アイデアについて話しましょう。

1.スレッドプールの問題、スレッドが時間内にリサイクルされていないと思います。時間が長すぎます。同時実行数が多すぎて、スレッドが不十分になります。最初に頭に浮かぶのは、スレッドの数です増やす必要があります

2. データベース内のデータが多すぎると、クエリが以前よりも桁違いに遅くなり、最終的にキューがブロックされ、スレッドが引き下げられます (この可能性は比較的低く、データベースクエリはすぐに返されます。最適化が必要な遅い SQL)

3. 特定のメカニズムでループが少ない、またはループがないなど、このループが発生している疑いがあり、for ループを削除しても問題が解決しない

最初の「スパイ」を検証

最初にコアスレッドの数とスレッドの最大数を展開し、これら 2 つのパラメーターを 10 と 20 に展開します。

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

拡張後、装着してからデータが見られるようになり、大きな問題が解消された気がします

何と言うか、真実はそう簡単に見つからないことが多いです。最初に釣れたのは小魚とエビでした。予想通り、約 1 週間実行した後、同じ問題が再び発生しました。これは水槽のように感じます。、あなたは水タンクを大きくすると、一日でいっぱいになります。スレッドプールが大きいほど良いことは誰もが知っています。