Я работаю над приложением, которое имеет множество потоков, каждый из которых выполняет задачу, отличную от другой. Существует также ветка healthMonitor, которая отслеживает работоспособность отдельных потоков, отправляя сообщения пульса через регулярные промежутки времени. Среди этих потоков есть один поток T1, который отправляет сообщения другому потоку T2, в ответ на который T2 выполняет некоторую операцию записи файла.
В редких случаях T1 отправляет поток сообщений в течение продолжительного времени на T2, из-за чего T2 начинает выполнять операции записи в файл. Иногда эти операции записи в файл могут занимать много времени, занимая до 2 секунд. В этой ситуации T2 не отвечает на сообщения пульса, отправленные потоком healthMonitor, в результате чего поток healthMonitor завершает работу приложения.
T2 читает все входящие сообщения, включая сообщения, отправленные T1, и сообщения звукового удара, отправленные веткой healthMonitor, из того же сообщенияQueue.
Эта проблема возникает очень редко и не может быть воспроизведена по желанию, что затрудняет ее отладку.
Я пришел к выводу, что в таких ситуациях, когда имеется огромное количество сообщений, ожидающих обработки, а время обработки занимает слишком много времени, сообщения пульса остаются необработанными слишком долго. Из-за этого потока T2 не отвечает на поток HealthMonitor вовремя.
Мой вопрос: как правильно решить эту проблему? Я имею в виду несколько вариантов:
- Ограничить количество сообщений из потока T1. Такой подход уменьшит нагрузку на поток T2, но разве это элегантный способ справиться с ситуацией?
- Внедрение основанной на приоритете обработки в очереди сообщений: все сообщения сердцебиения могут добавляться в начало очереди сообщений, а не добавляться в хвост, чтобы сначала их забирали из очереди. Обратите внимание, что у нас есть собственная реализация очереди сообщений для связи между потоками.
- Или я должен просто сосредоточиться на оптимизации операции записи файла в потоке T2?