Столкнулись ли с падением приложения из-за большого количества потоков
Что проверяют
Проверяют, отличаете ли вы нехватку потоков от нехватки памяти и умеете ли читать дамп. По ответу сразу видно, разбирал кандидат реальное падение или пересказывает статью: у падения из-за потоков есть узнаваемая подпись, и человек, который её видел, называет её без подсказки.
Как отвечать
Назовите два разных падения. Первое: OutOfMemoryError: unable to create new native thread. Куча тут ни при чём, кончилась память под стеки или упёрлись в лимит процессов операционной системы; каждый поток стоит своего стека, и тысячи потоков съедают гигабайты мимо кучи. Второе: обычный OutOfMemoryError: Java heap space из-за очереди задач, которая растёт без предела.
Дальше про причину. Executors.newFixedThreadPool использует неограниченную LinkedBlockingQueue: потоков ровно столько, сколько заказали, а вот очередь копит задачи до конца кучи. newCachedThreadPool наоборот, заводит новый поток на каждую задачу, если свободных нет. Поэтому в проде пул собирают руками через ThreadPoolExecutor с ограниченной очередью и явной политикой отказа, например CallerRunsPolicy, которая притормаживает поставщика вместо тихого накопления.
Скажите, как диагностировали: jstack или jcmd Thread.print, группировка потоков по имени и состоянию, поиск общего места в стеках. Если все потоки стоят в BLOCKED на одном мониторе или ждут соединения из пула, дело не в количестве потоков, а в ресурсе за ними.
Где спотыкаются
Лечат симптом размером пула. Потоки добавляют, узкое место остаётся в базе или во внешнем вызове, и растёт только число ждущих вместе с расходом памяти под стеки.
Ссылаются на ReentrantLock и Semaphore как на средство от переполнения. Это примитивы синхронизации, они ограничивают доступ к участку кода, а не создание потоков, и от нехватки нативной памяти не спасают.
Обещают, что виртуальные потоки снимают вопрос. Они убирают цену самого потока, но не цену ресурса за ним: пул соединений к базе и лимиты внешнего сервиса остаются прежними, и переписанный код упирается в то же место, только быстрее.