ThreadPoolExecutor висит

Question

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

Мы должны обновить некоторое состояние X ресурса Y на удаленном сервере. У нас есть менеджер ресурсов, который изменяет состояние ресурса и обновляет X как побочный эффект изменения. Этот менеджер постоянно проверяет ресурс, и когда он считает, что ресурс обновлен, он использует команду ThreadPoolExecutor для выполнения этой работы. Этот исполнитель пула потоков имеет достаточно строчную очередь блокировки, но довольно небольшое количество максимальных потоков. Привязка себя от дампа потока происходит в вызове invokeAll (между прочим)

У нас есть основания полагать, что количество потоков core/max в этом исполнителе пула занято другими вещами (больше обновлений состояния ресурсов, если вы).

Поскольку invokeAll возвращает нам фьючерсы, на которые мы ждем, вопрос заключается в том, что invokeAll зависает, даже если структура блокирующих данных, используемая исполнителем, достаточно велика для выполнения работы, переданной через invokeAll, но нет доступных потоков?

Answer 1

Как и другие пользователи указали, без какого-либо кода (даже псевдо-код), а также более четкое понимание того, что «состояние X», и что такое «ресурсное Y» есть, это практически невозможно кто-нибудь здесь, чтобы дать разумный ответ. Короче говоря, вам нужен SSCCE. Тем не менее, я сделаю все возможное здесь ;-). И если вы отправляете почтовый код и/или предоставляете дополнительную информацию, я буду соответствующим образом обновлять свой ответ.

От Java 7 ExecutorService#invokeAll javadoc:

Выполнение поставленных задач, возвращая список фьючерсов, имеющих свой статус и результаты, когда все полные. Future.isDone() истинно для каждого элемента возвращаемого списка. Обратите внимание, что завершенная задача может завершиться либо нормально, либо путем исключения исключения. Результаты этого метода не определены, если данный сборник изменен во время выполнения этой операции.

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