questionerзапросов приходит много, работа, которую делает внешний сервис - долгаяВот навалилась на вас тысяча клиентов. Сначала прислали тысячу запросов, потом им отправлена тысяча ответов. Существует ненулевая вероятность, что в какой-то момент вам всё равно понадобится тысяча потоков.
Возникает вопрос: что лучше - узнать, что мы не можем обслужить тысячу потоков при старте приложения или упасть с OOM в процессе работы? Это первое.
Второе. 32-разрядная Oracle JVM может создать и обслужить тысячу потоков, но не может - две тысячи. И, если вам, кровь из носу, надо именно 32-разрядную Oracle JVM - да, потоки надо экономить.
Но есть ньюанс. Поскольку у меня есть и Oracle Hotspot и IBM J9, я сравнил четыре варианта - две JVM8 обоих разрядностей каждая.
Так вот, 32-разрядная IBM J9 прекрасно создаёт и обслуживает две тысячи потоков.
Учитывая, что все тесты делались на достаточно хилом десктопе (Athlon II X-2 250/3ГГц/6Гб), лично я хочу понять - насколько дохлым должен быть сервер, чтобы задача "минимизировать число потоков исполнения любой ценой" - вообще могла возникнуть.

P.S. У асинхронных сервлетов есть два назначения:
1. Получить от контейнера отдельный поток исполнения. Этот сценарий может и увеличить используемое число потоков;
2. Организовать цикл чтения/записи средствами контейнера. Этот сценарий может сэкономить число потоков.
Вы долбитесь в третий сценарий, который связан с созданием собственного пула потоков, что, в целом, не есть гут.

questionerНи во что я не долблюсь) всё получилось.
смотрите, приходит нам каждую секунду 100 запросов.
обработка - 1 минута. Обработка идёт на другой машине. она говотова исполнять сколько хочешь запросов но в любом случае это минута
При синхронных сервлетах - через 2 секунды потоки кончились - всё писец, приехали, новые запросы не принять.Уже здесь вы или нагло врёте или тупо не понимаете.
При ста HTTP-запросах в секунду IP-стек за минуту примет 60 тысяч подключений. Созданные 60 тысяч TCP-соединений будут существовать (при ваших исходных), как минимум, одну минуту - от подключения клиента до отправки ему последнего байта ответа.
Если ваша система в состоянии держать 60 тысяч TCP-соединений - 60 тысяч потоков исполнения не будут для неё слишком тяжким испытанием.
Лично я наблюдал JVM с ~15 тысячами потоков. Я сам создал эту стрессовую нагрузку и могу определённо утверждать, что ничего не зависло и всё работало. Сразу оговорюсь - активных потоков было на порядок меньше.questionerпри асинхронных поток контейнера положил задачу в мапу и всё, свободен. Внешняя система получает все запросы с такой же скоростью, что и сервлет.
и есть поток(ну или пул), который разгребает результаты.
Всё, проблема решена.
Что не так?Ну что ж, давайте разберём ваш вариант:questionerЕсть сервлет(он же контроллер в спринге)
внутри него пишется

То есть отправили сообщение в некую систему. id нужен для идентификации ответа.
система внешняя отвечает асинхронно.
то есть в другом потоке есть infinite lool внутри которого выполняется
Не я сказал "внешняя система", но я могу предположить, что с этой внешней системой мы общаемся по локальной сети.
Поскольку отсылки на авторитеты уже были, то и я позволю себе заметить, что IP-стек и умолчания для него делали весьма неглупые люди.
Так вот, тайм-аут записи составляет три, а чтения - пять минут. Если хотя бы один запрос вашего "infinite lool" (бесконечный цикл) повиснет - весь опрос будет остановлен на несколько минут.
Если, вдруг, опрос внешней системы станет чуточку медленнее (на десять миллисекунд для определённости) то с шестьюдесятью тысячами запросов (я вас за язык не тянул), потребуется лишних десять минут на очередную итерацию. Про закон подлости и "находится в последнем ящике" просто напомню.
Можно, конечно, и ещё поёрничать, но, блин, рано вам оптимизацией заниматься - пишите "как можно проще, лишь бы это работало".

Leonid KudryavtsevНаписали IMHO еще больший бред, чем у questioner. IMHO. NIO все же работает и не повисаетNIO/BIO ... Какая разница, кто кинет IOException???
Тем более, что никакого NIO в примере questioner нет. NIO в асинхронных сервлетах делается несколько по другому, нежели циклический опрос готовности внешнего сервиса.

Leonid KudryavtsevНо, если задачу можно решить двумя способами:
1) использовав 5-6 потоков и 512 Mb RAM
2) или сделать то же самое , с использованием 15 тысяч потоков и 20-30 Gb RAM.Вы совершенно напрасно не посмотрели то, что я выкладывал под спойлерами.

P.S. Читаете тоже невнимательно - я специально указывал число активных потоков.