[로그] 로깅퍼사드와 로거 선택

[choitaehoon]

로깅 퍼사드 종류

• commons Logging , slf4j


• JCL 문제점

              commons-logging의 기본 사용
              logger.debug("Hello"+i+String.valueOf(array[i])); 

• commons Logging의 문제점은 ?
• 로깅이 실행이 안되더라도 문자열을 처리하는데 String문자열 을 써서 심각해진다. String은 매번 새로 만들어질때 마다 객체를 생성하는데 객체를 많이 생성 하게 되면 힙 영역에 객체가 계속 쌓이게 되고 객체가 많이 쌓이게 되면 가비지 컬렉션이 일어나 모든 작업을 중단하고 가비지 컬렉션에 집중하게 된다. 이러한 작동은 작업 수행 시간을 늦출 수 있고 불필요한 행동이 반복된다. StringBuffer나 StringBuilder라면 모를까....

---

• commons Logging 문자열 해결 전략

                if(logger.isDebugEnabled()) {
                       logger.debug("Hello"+i+String.valueOf(array[i]));
                }
        

• 하지만 여전히 문제가 남게 되는데.... 코드가 더 지저분 해지고 두번 메소드가 호출 되는걸 볼 수 있다. isDebugEnabled() -> debug()

---

• 클래스 로더
• 전통 적인 자바 클래스 로더 방식은 부모 클래스 로더와 자식 부모 클래스 로더가 있다. 클래스 로드는 부모 클래스를 먼저 로딩한다. 그 이유는 효율성 인데 클래스 로더가 같이 사용하는 클래 스,리소스를 각자 사용하게 된다면 중복되는 로딩이 많을 것이다.그래서 부모 클래스 로더를 먼 저 로딩한다. 그렇게 할 경우 중복되는 로딩을 한번에 읽을 수 있기 때문이다 그래서 parent-first/child-last 방식이다


• WAS 클래스 로더
• 이미 로딩 되어 있고 라이브러리 버전을 1.0 에서 2.0으로 바뀌게 된다면 클래스 로더는 1.0을 읽 고 있다. 그래서 이미 로딩된 클래스로 취급하고 인식을 하지 못한다. 그래서 was에서는 parent-last/child-first 방식을 사용하고 있다. 다시 빌드해서 하면 되지 않겠냐는 생각이 들 수 있 지만 빌드가 이미 한번 실행되면 execution에서 JLT 컴파일에서 클래스 파일을 네이티브 코드로 변환 후에 1차 캐시에 저장하게 된다.그래서 클래스로더를 다 지우고 다시 실행해야만 한다.


• 그래서 등장한 slf4j
• 로깅 라이브러리를 런타임때 실행하는게 아니라 컴파일 시점에 정해지기 때문에 JCL에 발생한 클 래스 로더 문제를 해결 할 수 있다.


• slf4j 코드

    logger.debug("Hello {}.", world);

• 로깅 할때 파라미터를 {}로 받고 로깅하지 않을때는 문자열을 처리 하지 않는다. 런타임에 정하지 않기 때문에 의존성을 잘 처리해야한다. 로깅 하지 않을 때 문자열을 처리 하지 않는 다는 것은 String 객체가 생성되지 않아 힙 영역을 무리를 안준다는 뜻이다.그래서 commons Logging보다 좋을 수 밖에 없다.

---

로그 종류

• JUL, Log4J2, Logback
• Logback
• log4j보다 10배 정도 빠르게 수행되며 메모리 효율도 올라 갔다. 또한 Rolling FileAppender를 사용하면 자동으로 오래된 로그를 지울 수 있다.


• 이러한 장점으로 JCL+log4j에서 slf4j+logback으로 넘어가고 있다.

[aj1155]

@choitaehoon slf4j는 commons logging와는 다르게 로그를 실행하지 않으면 String문자열을 처 리 안해도 되는데 이는 매우 효율을 높일 수 있고 로깅 라이브러리를 컴파일 시점 에 실행 시킬 수 있어서 좋다. 이게 어떤 의미인지는 알고있는거지? ㅋㅋ