Что является лучшим способом и лучшим инструментом для входа в систему многопоточной среды, так, чтобы каждый поток имел свой собственный экземпляр регистратора и отдельный файл. это даже возможно?
Вы можете попробовать использовать пользовательское приложение Log4J, которое принимает идентификатор потока в качестве параметра и фильтрует сообщения в зависимости от того, какой поток его вызывает. Создайте его на лету, прикрепите к регистратору.
Однако у этого подхода есть несколько проблем:
Я предлагаю вам рассмотреть более простой подход: записать идентификатор потока в тот же файл журнала. Это быстро и просто, для этого в log4j есть флаг%. Позже вы можете использовать grep / разделить файл журнала по идентификатору потока, если это необходимо.
Обновление :
На самом деле у вас может быть одно настраиваемое приложение, которое будет открывать файлы журнала по запросу, когда новый поток регистрирует запись (приложение выполняется в контексте этого потока, просто вызовите Thread.currentThread () .getName ()). Но вам придется заново реализовать все обычные задачи файла журнала (ротация) или делегировать его стандартному приложению для каждого файла.
У меня есть многопоточное приложение, которое идентифицирует каждый поток в файле журнала (не знаю о нескольких файлах, один файл показывает мне совпадение), идентификация потока выполняется автоматически фреймворком ведения журнала, это Log4J
Изменить: Ничего не нужно добавлять в код, вы просто настраиваете приложение в регистраторе, чтобы включить [% Thread], который будет идентифицировать поток, из которого вы регистрируете текущее сообщение, это пример из log4net:
<appender name="AspNetTraceAppender" type="log4net.Appender.AspNetTraceAppender" >
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />
</layout>
Вот список других распространенных фреймворков ведения журналов Java
В некоторых случаях знание идентификатора потока гораздо менее важно, чем знание контекста выполнения. Это особенно актуально для большого количества потоков и крупных приложений. Что делать, когда идентификатор потока меняется, но фактический контекст выполнения остается прежним (как кто-то упоминал о пулах потоков)? Я бы предпочел использовать MDC (mapped diagnostic context) для отслеживания контекста выполнения в журналах. Это лучше, потому что вы контролируете, что такое контекст. В конце концов, вы можете настроить макет журналов, чтобы включить MDC, а затем легко отфильтровать то, что имеет отношение к делу. Посмотрите этот инструмент, он делает довольно много вещей с MDC.