JAVA

JVM, JDK, JRE란 무엇인가?

JRE

자바 실행 환경의 줄임말로 JVM에 자바 라이브러리와 기타 파일들이 결합된 자바를 실행하기 위한 프로그램입니다.

JDK

자바 개발 킷의 줄임말로 JRE에 컴파일러, 디버거 등 개발도구를 포함하는 프로그램입니다.

JVM

JVM은 Java Byte Code를 OS에 맞게 해석해 주는 역할을 합니다.

Java Compiler는 java파일을 class라는 Java byte code로 변환시켜줍니다. Byte Code는 기계어가 아니기 때문에 OS에서 바로 실행되지 않아 JVM이 OS가 ByteCode를 이해 할 수 있도록 해석 해줍니다.

이러한 JVM의 해석을 거쳐 C언어 같은 네이티브 언어에 비해 속도가 느리지만 JIT(Just In Time) 컴파일러를 구현해 이 점을 극복했습니다.

OS에 종속적이지 않고 Java 파일만 구성하면 어느 디바이스던 JVM 위에서 실행 할 수 있다는 점이 Java의 장점이라고 할 수 있습니다.

JVM은 크게 ClassLoader, Runtime Data Areas, Excution Engine 3가지로 구성되어 있습니다.

JVM 구조

Class Loader

RunTime 시점에 Class를 로딩하게 해주며 Class의 Instance를 생성하면 Class Loader를 통해 메모리에 로드하게 됩니다.

Runtime Data Areas

JVM이 프로그램을 수행하기 위해 OS로부터 별도로 할당 받은 메모리 공간을 말하며, Runtime Data Areas는 크게 5가지 영역으로 나눌 수 있습니다.

• PC Register : Thread가 생성될 때 마다 생기는 공간으로 Thread가 어떠한 명령을 실행하게 될지에 대한 부분을 기록합니다. JVM은 Stacks-Base 방식으로 작동 하는데, JVM은 CPU에 직접 Instruction을 수행하지 않고, Stack에서 Operand를 뽑아내 이를 별도의 메모리 공간에 저장하는 방식을 취하는데, 이러한 메모리 공간을 PC Register라고 합니다.

• Java Virtual Machine Stack : Thread의 수행정보를 Frame을 통해서 저장하게 됩니다. Thread가 시작될 때 생성되며, 각 Thread 별로 생성이 되기 때문에 다른 Thread는 접근할 수 없습니다. 대표적으로 Local Variable을 가집니다. Java Virtual Machine Stacks에서 현재 수행하고 있는 Frame을 CUrrent Frame이라고 하며, Stack Frame에는 Method의 Parameter Variable, Local Variable과 연산 결과를 저장하게 됩니다.

• Native Method Stack : JVM은 Native Method를 위해 Native Method Stack이라는 메모리 공간을 가집니다. Application에서 Native Method를 호출하게 되면 Native Method Stack에 새로운 Stack Frame을 생성하여 Push 합니다. 이는 JNI를 이용해 JVM 내부에 영향을 주징 않기 위함입니다. Native Method의 수행이 끝나면 해당 Method를 호출한 Stack Frame이 아닌 새로운 Stack Frame을 하나 생성하여 작업을 수행합니다.

• Method Area : 모든 Thread가 공유하는 메모리 영역입니다. Method Area는 Class와 Inerface의 ByteCode 및 메타 데이터가 저장 됩니다. 이는 Garbage Collection의 대상이 되며 Hotspot JVM의 경우 Permenent Area라는 명칭으로 사용됩니다. IBM JVM 같은 경우는 Heap 내에 Class Object 형태로 저장됩니다.

• Heap : Instance와 Array 객체 두 종류가 저장되는 공간입니다. Java Heap은 모든 Thread에 의해 공유된다고 하는데 그로 인해 동기화 문제가 발생 할 수 있습니다.

Execution Engine

Load 된 Class의 ByteCode를 실행하는 Runtime Module이 바로 Execution Engine입니다. Class Loader를 통해 JVM 내의 Runtime Data Areas에 배치된 바이트 코드는 Execution Engine에 의해 실행되며, 실행 엔진은 자바 바이트 코드를 명령어 단위로 읽어서 실행합니다.

가비지 컬렉터 작동 원리를 설명하시오

Java에서는 개발자가 프로그램 코드로 메모리를 명시적으로 해제하지 않기 때문에 가비지 컬렉터(Garbage Collector)가 더 이상 필요 없는 (쓰레기) 객체를 찾아 지우는 작업을 합니다. 이 가비지 컬렉터는 두 가지 전제조건에 의해 만들어졌다.

• 대부분의 객체는 금방 접근 불가능 상태(Unreachable)가 된다.
• 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

이 두가지 전제조건의 장점을 최대한 살리기 위해 HotSpot JVM에서는 크게 2개로 물리적 공간을 나누었다. 둘로 나눈 공간이 Young 영역과 Old 영역이다.

• Young 영역(Young Generation 영역) : 새롭게 생성한 객체의 대부분이 여기에 위치합니다. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라집니다. 이 영역에서 객체가 사라질 때 Minor GC가 발생한다고 말합니다.

• Old 영역(Old Generation 영역) : 접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사됩니다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생합니다. 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC)가 발생한다고 말합니다.

Young 영역에서의 GC(Minor GC)

Young 영역은 3개의 영역으로 나뉩니다.

• Eden 영역
• Survivor 영역 (2개)

Survivor 영역이 2개이기 때문에 총 3개의 영역으로 나뉩니다. 각 영역의 처리 절차를 순서에 따라 기술하면 다음과 같습니다.

1. 새로 생성한 대부분의 객체는 Eden 영역에 위치한다.
2. Eden 영역에서 GC가 한 번 발생한 후 살아남은 객체는 Survivor 영역 중 하나로 이동된다.
3. Eden 영역에서 GC가 발생하면 이미 살아남은 객체가 존재하는 Survivor 영역으로 객체가 계속 쌓인다.
4. 하나의 Survivor 영역이 가득 차게 되면 그 중에서 살아남은 객체를 다른 Survivor 영역으로 이동한다. 그리고 가득 찬 Survivor 영역은 아무 데이터도 없는 상태로 된다.
5. 이 과정을 반복하다가 계속해서 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

Old 영역에 대한 GC(Major GC)

Major GC는 GC방식에 따라 처리 절차가 달라지지만 기본적으로는 아래와 같습니다.

1. Old 영역에 있는 모든 객체들을 검사하며 참조되고 있는지 확인합니다.
2. 참조되지 않은 객체들을 모아 한 번에 제거합니다.

Minor GC보다 시간이 훨씬 많이 걸리고 실행중에 GC를 제외한 모든 쓰레드가 중지합니다.

SPRING

스프링부트 와 스프링의 차이를 설명하시오

스프링 프레임워크는 자바 생태계에서 가장 대중적인 응용프로그램 개발 프레임워크입니다. 의존성 주입(DI, Dependency Injection)과 제어의 역전(IOC, Inversion Of Control)은 스프링에서 가장 중요한 특징중 하나입니다. 이들로 인해서 좀더 결합도를 낮추는 방식으로 어플리케이션을 개발할 수 있습니다. 이러한 개발방식으로 개발한 응용프로그램은 단위테스트가 용이하기 때문에 보다 퀄리티 높은 프로그램을 개발할 수 있습니다.

스프링부트는 자동설정(AutoConfiguration)을 이용하였고 어플리케이션 개발에 필요한 모든 내부 디펜던시를 관리합니다. 개발자가 해야하는건 단지 어플리케이션을 실행할 뿐입니다. 스프링의 jar파일이 클래스 패스에 있는 경우 Spring Boot는 Dispatcher Servlet으로 자동 구성합니다. 마찬가지로 만약 Hibernate의 jar파일이 클래스 패스내에 존재한다면 이를 datasource로 자동설정하게 됩니다. 스프링부트는 미리설정된 스타터 프로젝트를 제공합니다.

웹어플리케이션을 개발하는 동안, 우리는 사용하려는 jar, 사용할 jar 버전, 함께 연결하는 방법이 필요합니다. 모든 웹 어플리케이션에는 Spring MVC, Jackson Databind, Hibernate 코어 및 Log4j와 같은 유사한 요구사항들이 있습니다. 그래서 우리는 이러한 jar들의 서로 호환되는 버전들을 따로 선택을 해주어야 했습니다. 이런 복잡도를 줄이기 위해서 스프링 부트는 SpringBoot Starter라고 불리는 것을 도입했습니다.

스프링의 특징에 대해서 사용 사례를 빗대어 설명하시오

• AOP : 인증 처리 혹은 공통 로그 수집과 같은 횡단 관심사를 AOP를 통해서 구현 할 수 있습니다.
• DI : 객체간의 의존관계를 Dependency Injection을 통해서 수행 할 수 있습니다.
• PSA : 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근 할 수 있게 해줍니다.

스프링의 서비스 추상화란 무엇인지 설명하시오

추상화란 하위 시스템의 공통점을 뽑아내서 분리시키는 것을 말합니다. 그렇게 하면 하위 시스템이 어떤 것인지 알지 못해도, 또는 하위 시스템이 바뀌더라도 일관된 방법으로 접할 수가 있습니다. 스프링은 트랜잭션 기술의 공통점을 담은 트랜잭션 추상화 기술을 제공하고 있습니다. 트랜잭션을 관리하기 위한 인터페이스인 PlatformTransactionManager를 선언하고 각 DB에 대한 transactionManager 클래스를 DI해주면 트랜잭션 관련 코드는 통일되는 동시에 DB가 바뀐다면 DI설정만 교체해주면 트랜잭션 관련코드의 변경은 하나도 없게되며 이것이 서비스 추상화의 장점이라고 할 수 있습니다.

아키텍처

객체지향과 절차지향에 차이에 대해 설명하시오

절차지향 프로그래밍은 순차적인 처리가 중요시 되며 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법입니다. 이는 컴퓨터의 작업 처리 방식과 유사하기 때문에 객체지향 언어를 사용하는 것에 비해 더 빨리 처리 되어 시간적으로 유리하지만 실행 순서가 정해져 있으므로 코드이 순서가 바뀌면 동일한 결과를 보장하기 어렵다는 단점이 있습니다.

객체지향 프로그래밍은 실제 세계를 모델링하여 소프트웨어를 개발하는 방법입니다. 객체지향 프로그래밍에서는 데이터와 절차를 하나의 덩어리로 묶어서 생각하게 됩니다.코드의 재활용성이 높고 디버깅이 쉽다는 장점이 있지만 어떤 모듈에 있는 하나의 기능만 필요하더라도 모듈 전체를 가져와야 하기 때문에 절차지향 프로그래밍보다 프로그램 사이즈가 더 커질 수도 있고 메소드를 통해서만 접근이 가능하기 때문에 절차지향식처럼 특정 함수에 접근 할 수 없고 식으로만 접근이 가능해 속도적인 측면에서 불이익이 있다는 단점이 있습니다.

SOLID 원칙에 대해 아는대로 설명하시오

객체지향 설계에서 지켜줘야 할 5개의 원칙(SRP, OCP, LSP, ISP, DIP)을 말합니다.

1. SRP(Single Responsibility Principle) 단일 책임원칙 객체는 단 하나의 책임만 가져야 한다는 원칙을 말합니다. 객체에 책임이 많아질수록 클래스 내부에서 서로 다른 역할을 수행하는 코드끼리 강하게 결합될 가능성이 높아집니다. 즉, 객체마다 책임을 제대로 나누지 않는다면 시스템은 매우 복잡해지기 때문에 책임을 분리 시킬 필요가 있습니다.

2. OCP(Open-Closed Principle) 개방 폐쇄원칙 기존의 코드를 변경하지 않으면서(closed), 기능을 추가할 수 있도록(open) 설계가 되어야 한다는 원칙을 말합니다. 즉, 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다는 의미를 갖습니다. 이를 만족하는 설계가 되려면, 캡슐화를 통해 여러 객체에서 사용하는 같은 기능을 인터페이스에 정의하는 방법이 있습니다.

3. LSP(Liskov Substitution Principle) 리스코프 치환원칙 자식 클래스는 최소한 부모 클래스에서 가능한 행위는 수행 할 수 있어야 한다는 설계 원칙입니다. 자식 클래스는 언제나 부모 클래스의 역할을 대체할 수 있어야 한다는 것을 말하며, 부모 클래스와 자식 클래스의 행위가 일관됨을 의미합니다. 즉, 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 LSP를 만족하게 됩니다.

4. ISP(Interface Segregation Principle) 인터페이스 분리 원칙 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 설계 원칙입니다. 즉, 하나의 거대한 인터페이스 보다는 여러개의 구체적인 인터페이스가 낫다는 것을 의미합니다. SRP는 객체의 단일 책임을 뜻한다면, ISP는 인터페이스의 단일 책임을 의미합니다.

5. DIP(Dependency Inversion Principle) 의존 역전 원칙 객체들이 서로 정보를 주고 받을 때 의존 관계가 형성되는데, 이 때 객체들은 나름대로의 원칙을 갖고 정보를 주고 받아야 한다는 설계 원칙입니다.

캡슐화에 대해 설명하시오

외부 객체에서 구현방식은 알 수 없도록 숨기고 별도로 접근 할 수 있는 getter/setter 메소드를 통해 접근하도록 하는 방식으로 내부 구현의 변경으로 인해 외부의 객체가 영향을 받으면 안됩니다.