[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-mnogopotochnost-chto-budet-esli-ochered-pula-potokov-uzhe-zapolnena-no-podayotsya-novaya-zadacha":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":20,"progress":21,"seo":22},267,"chto-budet-esli-ochered-pula-potokov-uzhe-zapolnena-no-podayotsya-novaya-zadacha",8,"mnogopotochnost","Многопоточность","🔀","Что будет, если очередь пула потоков уже заполнена, но подаётся новая задача?","\u003C!-- grade: 3\u002F5 — ответ слишком краткий, не раскрыты стратегии отклонения -->\n\nЕсли все потоки пула заняты **и** очередь задач заполнена **и** достигнут `maximumPoolSize`, вступает в действие **политика отклонения задач** (`RejectedExecutionHandler`).\n\n### Встроенные политики отклонения\n\n| Политика | Поведение | Когда использовать |\n|---|---|---|\n| `AbortPolicy` (по умолчанию) | Выбрасывает `RejectedExecutionException` | Когда потеря задачи недопустима и вызывающий должен об этом узнать |\n| `CallerRunsPolicy` | Задача выполняется **в потоке вызывающего** (`main`, HTTP-thread и т.д.) | Когда нужен «обратный нажим» (backpressure) -- вызывающий поток замедляется |\n| `DiscardPolicy` | Задача молча отбрасывается | Когда допустима потеря задач (телеметрия, логи) |\n| `DiscardOldestPolicy` | Удаляется самая старая задача из очереди, новая ставится на её место | Когда свежие данные важнее старых |\n\n### Пример конфигурации\n\n\u003Cdetails>\n\u003Csummary>Пример: ThreadPoolExecutor с CallerRunsPolicy\u003C\u002Fsummary>\n\n```java\nThreadPoolExecutor executor = new ThreadPoolExecutor(\n    2,                          \u002F\u002F corePoolSize\n    4,                          \u002F\u002F maximumPoolSize\n    60, TimeUnit.SECONDS,       \u002F\u002F keepAliveTime\n    new ArrayBlockingQueue\u003C>(10), \u002F\u002F Ограниченная очередь на 10 задач\n    new ThreadPoolExecutor.CallerRunsPolicy() \u002F\u002F Политика отклонения\n);\n\n\u002F\u002F Если все 4 потока заняты и очередь из 10 задач заполнена:\n\u002F\u002F 15-я задача выполнится в потоке вызывающего (main)\nfor (int i = 0; i \u003C 20; i++) {\n    final int taskId = i;\n    executor.execute(() -> {\n        System.out.println(\"Задача \" + taskId\n            + \" в потоке \" + Thread.currentThread().getName());\n        try { Thread.sleep(1000); } catch (InterruptedException e) { }\n    });\n}\n\nexecutor.shutdown();\n```\n\n\u003C\u002Fdetails>\n\n### Собственная политика отклонения\n\nМожно реализовать `RejectedExecutionHandler`:\n\n```java\nRejectedExecutionHandler customHandler = (runnable, executor) -> {\n    logger.warn(\"Задача отклонена: очередь переполнена!\");\n    \u002F\u002F Записать в очередь повторных попыток, отправить в Dead Letter Queue и т.д.\n};\n```\n\n### Важные нюансы\n\n1. **Неограниченная очередь** (`LinkedBlockingQueue` без capacity) -- никогда не заполнится, поэтому `RejectedExecutionHandler` **не вызывается**, но приложение может упасть с `OutOfMemoryError`. Пулы `newFixedThreadPool()` и `newSingleThreadExecutor()` используют неограниченную очередь -- это потенциальная проблема.\n2. **`submit()` vs `execute()`** -- при `AbortPolicy` оба выбрасывают `RejectedExecutionException`, но `submit()` сохраняет его в `Future`.\n3. **`CallerRunsPolicy` как backpressure** -- самая полезная в production: вызывающий поток замедляется, что естественным образом ограничивает поступление новых задач.\n\n> **Аналогия из жизни.** Ресторан полностью занят и все столики зарезервированы. Пришёл новый гость. `AbortPolicy` -- «Извините, мест нет» (отказ). `CallerRunsPolicy` -- «Официант, обслужи гостя сам, прямо у стойки» (вызывающий сам делает работу). `DiscardPolicy` -- гость молча разворачивается и уходит. `DiscardOldestPolicy` -- выгоняют того, кто дольше всех сидит.\n\n> **На собеседовании.** Назовите все 4 встроенные политики и опишите когда какую использовать. Подчеркните опасность `newFixedThreadPool()` с неограниченной очередью -- это частая причина `OutOfMemoryError` в production. Рекомендуйте явно создавать `ThreadPoolExecutor` с `ArrayBlockingQueue` и `CallerRunsPolicy` для production-систем.","","middle",[15,16,17,18,19],"RejectedExecutionHandler","очередь","thread pool","RejectedExecutionException","concurrency",[],null,{"title":23,"description":24,"ogTitle":25,"ogDescription":26,"keywords":27,"schemaAnswer":30,"featuredSnippetReady":31},"Переполнение очереди пула потоков — RejectedExecutionHandler — Gymterview","При заполненной очереди задача отклоняется: submit() выбрасывает RejectedExecutionException и вызывается RejectedExecutionHandler.","Очередь пула потоков заполнена — что произойдёт?","Задача отклоняется: submit() выбрасывает RejectedExecutionException, срабатывает RejectedExecutionHandler.",[28,18,15,29],"очередь пула потоков заполнена Java","thread pool overflow","Задача будет отклонена. Метод submit() у ThreadPoolExecutor выбрасывает RejectedExecutionException, после чего вызывается RejectedExecutionHandler.",true]