[ static ], [ final ]

final

해당 변수나 객체를 초기화한 이후에는 절대로 바꾸지 못하도록 선언하는 것 초기화가 되고 나면 그 이후에는 절대

값을 바꿀 수 없다. 당연히 클래스에서 상속, 확장 불가이고 메소드는 오버라이딩은 불가, 오버로딩은 가능하다.

메모리에 올라간다.

 

※ [ 면접을 위한 CS 전공 노트 지식 ]

→ 프로세스의 메모리 구조 중 const(java에서 C언어와 비슷한 의미)는 Data영역에 Bss Segment와 Data Segment로 나누어진다고 한다. 그러나 java의 final은 Data영역으로 메모리가 할당되는 것이 아니라 힙에 할당된다. 책이 틀린 것은 아니고 Java입장에서는 잘못됐다고 할 수 있다.

 

static

선언을 하게 되면 그 위치에 상관없이 프로그램의 시작부터 끝까지 메모리에 할당돼 있으면서

그 값을 마음대로 바꿀 수 있는 것

 

 

======== ======== ======== ======== ======== ======== ======== ======== ======== ======

                                                                         개인적인 의문점

======== ======== ======== ======== ======== ======== ======== ======== ======== ======

 

1. static final과 final의 차이

final을 쓰나 static final을 쓰나 둘 다 변할 수 없는 수(상수)인 것은 맞다. 그러나 static같은 경우는

메모리가 Data영역에 존재해 계속해서 유지한다. final은 GC에 의해 쓸모없어지면 해제 된다.

 

2. static final을 쓰는 경우

자주 쓰고 공통적으로 쓰는 기능을 사용한다. 그 이유는 매번 객체를 생성할 때마다 GC에 의해 메모리가 생성되고

해제되고 하는 것은 비효율적일 수 있다. 자주 쓰거나 공통적으로 쓰는 기능은 아예 메모리에 올려놓고 GC의 일을 줄여

주는 것이다.

 

3. 그럼 싱글톤 패턴 만들어서 다 공유하면 되는 거 아냐?

 

전역 상태: 싱글톤은 전역 상태를 유지하므로 다른 부분에서 예상치 못한 영향을 줄 수 있다. 여러 부분에서 같은 인스턴스에 접근하면 상태가 공유되어 의도치 않은 상호작용이 발생할 수 있다.

 

테스트 어려움: 싱글톤은 다른 클래스와 강하게 결합되어 있어 테스트가 어려울 수 있다. 특히 싱글톤 인스턴스가

다른 클래스에 의존적인 경우, 이를 모의(mock) 객체로 대체하거나 테스트하기가 어려울 수 있다.

 

 

생명주기 관리: 싱글톤 인스턴스의 생명주기를 관리해야 한다. 특히 어플리케이션의 초기화와 종료 시점에서 싱글톤이

적절히 초기화되고 제거되어야 할 수 있습니다. 이를 신경쓰지 않으면 메모리 누수(leak)가 발생할 수 있다.

 

멀티스레드 환경에서의 동기화 문제: 싱글톤이 멀티스레드 환경에서 사용될 경우 동기화 문제가 발생할 수 있다.

특히 lazy initialization 방식을 사용하는 경우에는 여러 스레드가 동시에 인스턴스를 생성하려는 시도를 막기 위해

동기화 메커니즘이 필요하다.

 

4. AOP vs 싱글턴(요약)

AOP : 관심사를 모듈화해서 반복적으로 발생하는 로직을 한 곳에서 관리하고자 할 때

           → 대표적인 예를 들면 interceptor도 그 중 하나라고 할 수 있다. 즉 Controller를 타기 전과 후의 반복적으로

                발생하는 로직을 한 곳에서 관리하기 때문이다.

 

싱클턴 : 객체의 인스턴스가 오직 하나만 생성되도록 한 후 전역적으로 쓰일 때