"이렇게 써라!!"
private final Logger logger = LoggerFactory.getLogger(this.getClass());
1. 분석
1) static으로 선언한 이유 :
static을 선언하면 클래스 변수로 객체 생성이 될 때마다 해당 객체를 매번 생성하지 않고 초기 클래스 로딩 시 한 번만 생성해서 사용하게 된다. 그러나, Spring에서는 객체를 굳이 싱글턴 형태로 디자인하지 않아도 객체를 싱글턴과 같이 한 번만 생성해서 사용하게 된다.
따라서 무조건적인 static을 선언해 Perm 영역의 공간을 소비하지는 말자.
또한, 직렬 화하는 것을 피할 수 있다.
(Perm영역이란? Permanent Generation의 약자로 객체의 생명주기가 영구적일 것으로 생각되는 객체를 관리한다. )
2) final으로 선언한 이유:
로그를 찍는 경우 Logger는 초기 생성된 이후 변경될 필요가 없다. 따라서 final로 선언하여 유지보수와 가독성을 높이기 위함이다.
3) LOGGER라는 대문자로 변수 선언한 이유:
Java에서 상수 선언시 통상적으로 대문자를 많이 사용한다. static final의 멤버 변수의 경우 상수 선언 시 많이 사용되고, 따라서 관행상 대문자로 변수명을 짓게 된 것이다.
4) 기능 : Console 창에 해당 로그가 찍힌다. 따라서 프로그램이 오류 발생 시 어디서 어떤 이유로 오류가 발생하는지 알 수 있어 이슈 처리가 용이하다.
2. 사용예시 (나의 게시판 프로젝트)
private static final Logger LOGGER = LoggerFactory.getLogger(BoardCtr.class);
/**
* 게시판 트리 ajax
* @param response
*/
@RequestMapping("/boardListByAjax")
@ResponseBody
public void boardListByAjax(HttpServletResponse response){
List<?> listview = boardGroupSvc.selectBoardGroupList();
TreeMaker tm = new TreeMaker();
String treeStr = tm.makeTreeByHierarchy(listview);
response.setContentType("application/json;charset=UTF-8");
try {
response.getWriter().print(treeStr);
}catch (IOException ex){
LOGGER.error("boardListByAjax");
};
}
3. StackOverFlow 의 자세한 설명
"이렇게 써라!!"
private final Logger logger = LoggerFactory.getLogger(this.getClass());
1) 이렇게 선언하면 어느 클래스에서든 변경 없이 사용 가능.
2) static을 선언해야 하는지에 대하여..(클래스 변수 선언 vs. 인스턴스 변수 선언에 따른 장단점.
a. Advantages for declaring loggers as static
- common and well-established idiom
- less CPU overhead: loggers are retrieved and assigned only once, at hosting class initialization
- less memory overhead: logger declaration will consume one reference per class
b. Disadvantages for declaring loggers as static
- For libraries shared between applications, not possible to take advantage of repository selectors. It should be noted that if the SLF4 J binding and the underlying API ships with each application (not shared between applications), then each application will still have its own logging environment.
- not IOC-friendly
c. Advantages for declaring loggers as instance variables
- Possible to take advantage of repository selectors even for libraries shared between applications. However, repository selectors only work if the underlying logging system is logback-classic. Repository selectors do not work for the SLF4J+log4 j combination.
- IOC-friendly
d. Disadvantages for declaring loggers as instance variables
- Less common idiom than declaring loggers as static variables
- higher CPU overhead: loggers are retrieved and assigned for each instance of the hosting class
- higher memory overhead: logger declaration will consume one reference per instance of the hosting class
e. Explanation
Static logger members cost a single variable reference for all instances of the class whereas an instance logger member will cost a variable reference for every instance of the class. For simple classes instantiated thousands of times there might be a noticeable difference.
However, more recent logging systems, e.g log4j or logback, support a distinct logger context for each application running in the application server. Thus, even if a single copy of log4j.jar or logback-classic.jar is deployed in the server, the logging system will be able to differentiate between applications and offer a distinct logging environment for each application.
More specifically, each time a logger is retrieved by invoking LoggerFactory.getLogger() method, the underlying logging system will return an instance appropriate for the current application. Please note that within the same application retrieving a logger by a given name will always return the same logger. For a given name, a different logger will be returned only for different applications.
If the logger is static, then it will only be retrieved once when the hosting class is loaded into memory. If the hosting class is used in only in one application, there is not much to be concerned about. However, if the hosting class is shared between several applications, then all instances of the shared class will log into the context of the application which happened to first load the shared class into memory - hardly the behavior expected by the user.
◎ 참고자료 : 1. https://atin.tistory.com/639
'Back-end > Java Language' 카테고리의 다른 글
X. GarbageCollection(가비지 컬렉션) (0) | 2021.06.10 |
---|---|
입출력(I/O) (0) | 2021.06.07 |
JVM(Java Virtual Machine)? (0) | 2021.06.04 |
함수의 호출 방법 : Call By Value와 Call By Reference (0) | 2021.06.03 |
접근 제어자(access modifier) (0) | 2021.05.25 |