Logback이 별도의 스레드를 사용하지 않아 log4j와 같은 구성 파일을 감시하여 종료 문제가 발생하지 않는다고 들었습니다. 그러나 나는 그들이 그것을 어떻게 구체화하는지에 대해 이야기하는 어떤 물질도 발견 할 수 없었다. 로그백 메일 목록에는 2007 년까지 논의 된 내용이 있습니다. 누구나 메커니즘에 대해 이야기하는 자료를 가르쳐 줄 수 있습니까, 찬성 & 죄수 팀? 감사합니다logback에서 파일 구성을 감시하는 방법
모든 로깅 호출을 래핑하는 TurboFilter을 사용합니다. 타이머가 경과하면 16 개의 로깅 호출마다 타이머가 점검되고, 실행중인 경우 구성 파일의 수정 여부가 검사됩니다.
그래서 로그 메소드 호출시 약간의 시간을 훔쳐 별도의 스레드를 피할 수 있습니다.
Log4j의 파일 감시 스레드는 응용 프로그램 환경에서 문제를 일으킬 수 있습니다. 그래서 나는 pojo 프로그램에서 여전히 안전하다고 생각해. 그렇지? – ying
그 스레드를 중지하는 것이 전부입니다. 데몬 스레드라면 일반 Java 응용 프로그램에서 안전합니다. –
고마워, @ marko-topolnik. 로그백과 관련하여 후속 질문이 있습니다. 귀하의 응답을 감사하십시오. 2 env env1 : 로그 호출자가 직접 logback을 호출합니다. env2 : 대기열이 로그 호출자와 로깅 스레드를 분리합니다. log 문은 case 1이 될 수 있습니다. log.debug ("this is % s", s); case 2. log.debug (s); 로그 가드 없이는 인수 문자열 "s"가 위의 모든 경우에 logback 메서드 스택을 호출하기 전에 평가할 수 없다는 것을 이해하지 못합니다. 단일 JVM에서 힙을 공유하기 때문입니까? – ying
파고 약간했지만 모든 것을 찾지 못했습니다. [시작하는 것이 좋습니다.] (https://github.com/ceki/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/joran/spi/ ConfigurationWatchList.java) –