JVM
Java 어플리케이션이 플랫폼 종속적이지 않고, 어디서든지 동작하게 하기 위한 가상 머신이다. (Java Virtual Machine)
JVM 아키텍처
대략적으로 이해하고, 별도로 다시 글을 작성하겠다.
Class Loader
런타임 중 동적으로 클래스(.class, Byte Code로 작성됨)를 Runtime Data Area의 Method Area에 로드한다.
필요할 때 까지 로드하지 않는, Lazy-loading을 보여준다.
- 이 때 클래스를 로드하는 것은 인스턴스를 만들거나 초기화하는 것과는 아예 다른 이야기이다!!
Runtime Data Area
이름처럼 JVM 실행 시 운영체제로부터 할당받는 메모리다.
용도에 따라서 5개로 나누어진다.
Execution Engine
JVM 메모리(Method Area)에 적재된 Byte Code를 실행해주는 놈.
Interpreter
Byte Code를 한줄 한줄 해석해서 실행. 속도가 조금 느릴 수 있음.
JIT
Just-in-time compilation - Wikipedia
In computing, just-in-time (JIT) compilation (also dynamic translation or run-time compilations) is a way of executing computer code that involves compilation during execution of a program (at run time) rather than before execution.
실행 전(AOT)이 아닌, 런타임 중에 컴파일을 진행해 자주 쓰는 코드를 기계어로 컴파일 해두고 사용한다.
Method Area의 Code Cache 공간에 컴파일 된 코드를 캐싱해두고 사용해서 Interpreter보다 개선된 성능을 가진다.
JVM 메모리 구조
Runtime Data Area
Method Area, Heap Area는 쓰레드 간 공유된다.
Method Area
클래스 데이터(바이트 코드)와 static 변수가 저장됨
쓰레드 간 공유되는 공간이다.
Heap Area
힙 영역. new를 통해 동적으로 생성한 객체가 저장된다.
Garbage Collection의 대상
역시 쓰레드 간 공유되는 공간이다.
Stack Area
스택 영역. 지역 변수(매개 변수 포함)와 메소드 정보가 Frame 단위로 저장됨. 메소드 실행시 push, 완료 시 pop
- LVA: Local Variable Array
- OS: Operand Stack
- FD: Frame Data, 특정 메소드와 관련된 모든 참조와 리턴이 저장된다.
PC Registers
JVM의 Program Counter 저장
즉, 다음 실행할 명령어 주소
Native Method Stack
Java가 아닌 Native Method를 실행하기 위한 공간.
이건 JIT와 관련있어 보인다(개인 생각)
static
무엇?
정적 변수다. static 변수/메서드는 클래스에서 관리되므로, 메소드 영역에 클래스가 로드 될 때 함께 로드된다.
인스턴스가 아니라, 클래스에 속한다
Garbage Collection의 대상이 아니며 어플리케이션의 실행과 함께 로드되고, 종료와 함께 제거된다.
왜 사용?
상수, 공용으로 사용, 인스턴스 초기화하지 않고 사용
왜 지양하자는 거지?
StackOverflow - Why static variables considered evil
StackOverflow - Why aren't static methods considered good OO practice?
를 참고했다.
어플리케이션과 동일한 라이프사이클
켤 때부터, 끌 때까지 메모리에 상주
생성/소멸 제어 불가
Not Thread-Safe
당연하게도 여러 쓰레드가 한 자원을 공유하므로 쓰레드 세이프하지 않다.
쓰기가 가능하다면 분명 데이터 레이스 컨디션이 발생한다.
(
final이라도 재할당이 아닌 쓰기 자체는 가능할 수 있다)
오버라이딩 불가
OOP 패러다임의 특성인 다형성을 잘 활용하지 못한다.
테스트의 어려움
공용이므로 여기저기서 접근한다.
추적하기 어려울 수 있다.
예상 객체, 실제 객체의 구분이 의미 없어지는 경우가 생긴다.
이 경우 assertion을 하는 순서가 아주 상관있어지기 때문에
절차 지향적인 특성이 강하게 보이게 된다.
왜 객체 지향적이지 못한가?
강한 결합도
Static methods cause tight coupling, which is a violation of good Object Oriented Design. The tight coupling of the calling code and the code within the static method cannot be avoided through Dependency Inversion because static methods inherently don't support object-oriented design techniques such as Inheritance and Polymorphism.
Besides static methods are difficult to test because of these tightly-coupled dependencies, which oftentimes lead to third-party infrastructure that the code depends upon - like a database, and it makes it very difficult to change the behavior without actually going in and changing the code.
재사용성, 캡슐화 등
Static methods aren't considered good OO practice due to below reasons:
1) Prevents from Re-usability:
Static methods can't be overriden. It can't be used to in interface.
2) Object Lifetime is very long:
Static methods remain in the memory for a long time and its garbage collection takes long time. Developer's don't have control on destroying or creating of Static variables. Excessive usage of static variables can result in the memory overflow.
3) Also, some other points:
It doesn't respect the encapsulation because object does't remain in the complete control of its state. It doesn't follow concepts like Inversion of control, loose coupling, dependency injection, etc.
