uid unique https://www.javacodegeeks.com/2013/08/async-servlet-feature-of-servlet-3.html Вообще нет собственного пула. То, что разработчик получает информацию о текущем потоке - вообще никак не связано с асинхронными сервлетами.
Хотя за sleep() вместо wait() надо просто выписывать отдельных люлей в любом коде.
http://www.journaldev.com/2008/async-servlet-feature-of-servlet-3


Если это не кастомные пулы, то мне привиделось.Не привиделось.
Только, опять-таки, этот говнокод никак не связан асинхронностью. Если только тем, что для асинхронных сервлетов это совсем говнокод.

P.S. "И не в нарды, а в префереанс. И не диван, а дачу. И не выиграл, а проиграл".

questionerВ итоге у меня сложилось впечатление, что асинхронные сервлеты позволяют экономить на количестве созданных потоков.
В синхронных сервлетах если нам пришла задача мы обязательно создавали поток и он жил столько же сколько и задача.Неверно.
Пулом потоков всегда управляет контейнер. И от (а)синхронности сервлета этот факт не зависит.
API асинхронных сервлетов позволяет явно передать управление вводом-выводом контейнеру, а это, в свою очередь, позволяет разработчику контейнера оптимизировать использование пула потоков в некоторых сценариях.
Типичный такой сценарий - малоактивные клиенты и/или клиенты на медленных каналах связи.
Второй сценарий, наоборот, позволяет сервлету (неявно) запрашивать дополнительные потоки исполнения, что даёт возможность одновременной (параллельной) обработки в сервлете запроса и ответа.

P.S. Соглашусь, что в очень нагруженных системах надо экономить всё, включая потоки, но "меня опять терзают смутные сомнение", что тех, кому эти потоки надо экономить можно пересчитать по пальцам одной руки.

Leonid KudryavtsevВидел 40 ядерный сервер под реальной нагрузкой, даже 3-5 тыс. потоков по графикам для него было уже "тяжело". Хотя CPU использовалось процентов на 10-20%. Линух Убунту, куча микросервисов под докером"Вот тут-то вы его и засветили" (ц) старый пошлый анекдот.
JVM хороша тем, что это один процесс и накладные расходы на организацию взаимодействия между потоками - минимальны.
"Куча микросервисов под докером" это куча отдельных процессов и накладные расходы на организацию между процессами - максимальны.

P.S. Для JVM (Java6) на 32-разрядном Windows Server (2x4C/4Гб ОЗУ) "рубежом" были ~1500 потоков.
Сдыхало всё где-то на 3,2 тысячах потоков. Правда в нашем случае было приложение "с родовыми утечками" и система не "хайлоад".

Leonid KudryavtsevЕсли можно и не тяжело, киньте ссылку на нормальную доку как нужноКогда я переписывал один сервлет (маленький, но с двумя пакостными багами) - даже в голову не пришло создавать собственный пул.
Сервлет, конечно, был синхронный, но мысли создать собственный пул не возникло бы в любом сервлете.
Можно поинтересоваться - в каких задачах рука сама тянется к пистолету?

questionerОк, не мы, а контейнер в общем случае, но можно и свой пул использовать. Вот скажем в спринге есть для этого DefferedResult.
https://www.javacodegeeks.com/2015/07/understanding-callable-and-spring-deferredresult.html
Скорее всего у него под капотом асинхронные сервлеты.Вы совершенно напрасно не читаете документацию на используемые контейнеры.
Конкретно котяра может настраиваться или XML-файлами (предпочтительно) или в коде приложения (встраиваемый контейнер).
SpringBoot использует встраиваемый контейнер. Поэтому, естественно, настройка контейнера делается в коде. Код настраивает всё, включая пулы потоков исполнения.
Теперь я хочу понять, каким образом из этого следует что:
1. Ваше приложение может использовать пул, настроенный для контейнера?
2. Ваше приложение станет асинхронными сервлетом без всяких усилий с вашей стороны?
Но всё таки суть ведь в том, что имеем возможность принять на исполнение задачу от клиента даже если в пуле потоков места нет, а не просто создаём(контейнер-контейнер) поток на каждый запрос.Не можете вы принять задачу на исполнение, если у вас нет ресурсов.
Чтобы убедиться в этом достаточно напустить Apache Bench с большим параллелизмом на умалчиваемую конфигурацию котяры: пока контейнер не расширит пул с минимума до предложенной нагрузки - будете получать отлупы которые отобразятся и в статистике ab и в логе (на консоли) контейнера.
Отлупов будет немного, но они будут.допустим есть 10 потоков томката которые обрабатывают http запросы и пихают их в некоторый внутренний пул. Размер этого пула скажем 500 потоков. Каждая задача это обращение к внешней системе, которая отвечает минуту и ей пофиг на нагрузку.Задлянафига обсуждать конфигурацию, которая явно не соответствует условиям эксплуатации??? Чтобы посмотреть какие ошибки умеет выдавать контейнер? Ну так соберите и посмотрите.
Если у вас ожидается пиковая нагрузка в тысячу клиентов, а время обработки запроса достаточно велико, то коннектор должен быть настроен для приёма тысячи подключений, а пул потоков - для обработки тысячи запросов.
И тут нет предмета для обсуждения.

Leonid KudryavtsevIMHO & AFAIK в Java уже достаточно давно используются потоки OS. Т.ч. разница Java или C или что-то другое - быть не должноИменно об этом я говорю. Пока у вас одна JVM (один процесс операционной системы) вы можете навалить любую нагрузку, которую этот процесс выдержит и быть уверенным в том, что затраты на взаимодействие между потоками - минимальны.

Как только у вас появились микросервисы - у вас появилось много отдельных процессов системы. И взаимодействовать они должны по сети. В принципе, по виндой, обмен через локалхост по скорости сравним с обменом через память, но дополнительные накладные расходы никуда не делись.
Как только вы начинаете расселять микросервисы по отдельным контейнером вы добавляете ещё дополнительных расходов.

Конечный результат определяется характером задачи.
Если задачи микросервисов относительно объёмны - накладные расходы контейнеризации останутся приемлимо малыми.
Если задачи "совсем крохотные" - основное время будет съедено межпроцессным взаимодействием.
"Меня опять терзают смутные сомнения", что с этой точки зрения систему никто не анализировал: "когда в моде короткие юбки - не время думать о красоте ног".

Leonid KudryavtsevЕсли у нас штатно хватает 10 потоков, то настраивая на 1000, мы с большой вероятностью получим не ошибку, а просто полное зависание всей системы и, даже, возможно железа.Такой сценарий, разумеется нельзя исключить.
"Но есть ньюанс".
1. Плох тот сисадмин, который не знает возможности своего железа;
2. Если всё настолько плохо, что сдыхает уже на начальном этапе, когда потоки практически не потребляют ресурсов, возникает резонный вопрос что лучше:
2а - огрестись при старте приложения, когда других проблем ещё нет
или
2б - огрести проблему в часы наибольшей нагрузки, когда есть риск, что мы уже начали рвать волосы на разных местах
?Ситуация вида DoS /Denial of Service / атаки может быть не только из-за русских хаккеров ( TM ) но и из-за случайного стечения неудачных обстоятельств или ошибки.Вот поэтому ~примерно третий вариант моей реализации сервлета содержал код управления ресурсами. Причём, поразмыслив, я отверг оптимистичную стратегию и реализовал пессимистичную.Выполнить мы ее не можем (ресурсов не хватает), а вот принять на исполнения и пытаться выполнить (безуспешно) - это элементарно и сплошь и рядом такое происходит.Именно это и является ошибкой.
Если вы быстро и корректно дали дуба, то балансировщик, за которым вы, скорее всего, находитесь сможет "принять меры". А это, в свою очередь исключит ситуации, когда пользователи уже рвут и мечут, а вы ещё не понимаете, что проблемы уже начались.

Leonid Kudryavtsev, я помню это обсуждение.
Но вот лично я о NUMA системах знаю, только что они существуют и что для них есть дополнительные особенности. Как минимум - "доступ в чужую память".

Тем не менее.
1. Докер может быть лёгковесным средством изоляции процессов друг от друга в рамках физического хоста. Т.е. это вопрос организации безопасной среды исполнения с разграничением доступа;
2. Микросервисы или монолит - всё равно остаётся предметом для обсуждения.

Точнее так.
Если ваше железо справится с планируемой нагрузкой в любом варианте - делайте как удобнее.
Я не вижу плюсов у микросервисов, но это мои личные тараканы.
Если требуется "последний дюйм" без модернизации железа и среды исполнения, то монолит становится вполне реальным вариантом - модульность и компонентность ничуть ни хуже микросервисных. Меняются только стратегии развёртывания и администрирования.