У меня и моих товарищей по команде был аргумент «Дизайн», касающийся того, на каком уровне проект должен управлять количеством потоков на модуль?или за проект?Другой?мы хотели бы услышать больше мнений по этому вопросу (подумайте о поддержании кода, о хорошем коде, о рисках, таких как будущий тупик, голод и т. д.).
для целей обсуждения, которое мыдобавили нашу собственную мысль о плюсах и минусах каждого подхода.
Один подход ThreadPool - все модули в проекте будут внедрены с одноэлементным компонентом пула потоков (который будет иметь жесткую границуиз максимального потока, который понадобится службе).он будет расположен в общем модуле (см. структуру ниже).
Преимущества: -хороший контроль над потреблением потока; -снижение количества кода (компонент будет удален один раз).Недостатки: -не SOLID, каждый раз, когда одному модулю нужен поток, ему нужно перейти к другому модулю (общий) и изменить код.- Зависит от реализации пула потоков, может вызвать голодание.-deadlock / недостаточно потоков для продолжения работы, если одна задача зависит от другой И кто-то забыл добавить потоки.
(мой любимый) Per Need ThreadPool подход - все модули будут нести ответственность за количество потребляемого потока, более конкретно, в файле @Configuration каждого модуля, который вы можете увидеть, один или несколько bean-компонентов threadPool зависят от необходимости \ типа задачи.
Преимущества: - гибкость в управлении потоками.- контроль потоков на уровне модуля.- принцип открытия-закрытия на уровне модуля.- нет тупиковой ситуации / голодания, которые могут быть вызваны задачами других модулей.
Disatvategs: - без контроля уровня обслуживания.-много и разрозненное создание Бобов потоков по всему проекту.
Предполагается, что проект выглядит как структура ниже, а модуль зависит друг от друга относительно чисел (модуль-1 использует модуль-2, который использует модуль 3 ии так далее): * модуль 1 является исполняемым.
проект:
-комодуль-модуль
-модуль-1
-модуль-2
-модуль-3
-модуль-4