序文
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());
复制代码
拡張後は装着後にデータが見つかるようになり、大きな問題は解決した気がします
何というか、真実はそう簡単に見つからないことが多いです、最初に釣れるのは小魚やエビです、予想通り、一週間ほど走らせた後、また同じ問題が発生しました、ここは水槽のような気がします、水タンクを大きくすれば、いつか満杯になります。スレッド プールが大きいほど良いことは誰もが知っています。
では、真実は何でしょうか? すでに答えを知っている場合は、以下の答えを読まずに、コメント領域にアクセスして最初にコメントしてください。
GPT付き『名探偵コナン』
ここでは、chatgpt については多くを語りませんが、このことをまだ理解していない場合は、理解してください。。。どうか調べてもらうことしかできません
完全な製品コードを貼り付けると、次のように返信されました。
一言で言えば、思いつくことも思いつかないこともすべて答えるのに 5 秒しかかかりません
明らかに、2 番目のポイントと 3 番目のポイントの検証は基本的に合格しています。
那就是第一点了，其实我们早就应该想到这一点的，多线程环境下，线程安全问题是首位的！！！
找出"真凶"
使用synchronized关键字解决线程安全
使用synchronized关键字来同步访问all列表，即在多个线程访问all列表时，使用同一个锁来保证线程安全，避免出现数据不一致的问题。这样就解决了多个线程可能会同时访问并修改数据，导致数据丢失或损坏的问题。
聪明的你有没有找出“真凶”呢？？？
还记得我们加大线程数来解决问题吗，我又问了一个问题
扩大线程池的参数可能会提高程序的并发处理能力，但并不能从根本上解决问题。如果是由于数据同步问题导致的线程池查不到数据，那么扩大线程池只是把问题暂时推迟了而已。此外，扩大线程池的核心线程池数量也会占用更多的系统资源
AI已来，未来已来
再啰嗦一句，AI的强大这里就不再强调了 ,接下来我会持续利用GPT输出很多干货和其他AI生态的东西，都收在下方的AI专栏里，一起学习，一起成长，欢迎关注下方的AI专栏，点赞，谢谢各位看官