질문 - 답변 형식으로 정리
Call by reference란 무엇이고 보통 어떻게 쓰이나요?
"Call by value"는 메소드에 변수를 전달할 때 해당 변수의 값이 복사되어 메소드 내에서 사용됩니다. 이 때문에 메소드 내에서 변수 값을 변경해도, 호출한 측의 변수에는 영향을 주지 않습니다.
반면, "Call by reference"는 메소드에 변수의 참조(메모리 주소)를 전달하여, 메소드 내에서의 변경이 호출한 측의 변수에도 영향을 줍니다.
하지만 자바에서는 기본적으로 "Call by value" 방식을 사용하며, 객체 참조가 값으로 전달됩니다.
즉, 자바는 진정한 의미의 "Call by reference"를 지원하지 않습니다.
스프링에서는 주로 객체 참조를 전달하여 메소드 호출을 처리합니다.
이 방식을 통해 메소드 내에서 객체의 상태를 변경 할 수 있으며, 이 변경은 호출한 측에서도 반영됩니다.
이런 방식은 객체 지향 프로그래밍의 장점을 활용하여, 상태 관리와 예측 가능한 코드 실행을 용이하게 합니다.
예를 들어, 빈(bean) 객체의 상태를 변경하면, 스프링의 다른 부분에서도 이 변경이 반영되어 일관성을 유지할 수 있습니다.
Override 와 Overload 를 설명해주실 수 있을까요?
오버라이드(Override)는 상속받은 메서드를 하위 클래스에서 재정의하는 과정입니다.
이는 상위 클래스의 메서드와 동일한 시그니처(메서드 이름, 파라미터 타입 및 개수)를 가지지만, 메서드 내부의 로직이나 행위를 변경할 수 있습니다.
오버라이딩은 다형성을 지원하는 중요한 메커니즘입니다.
오버로드(Overload)는 동일한 이름을 가진 메서드를 여러 개 정의하지만, 각각 다른 파라미터의 타입이나 개수를 가질 수 있습니다.
이를 통해 하나의 메서드 이름으로 다양한 유형의 입력을 처리할 수 있으며, 이는 메서드 사용의 유연성을 증가시킵니다.
오버로딩은 메서드의 리턴 타입으로 결정되지 않으며, 파라미터의 차이에 의해 결정됩니다.
JPA는 언제 필요하고 언제 필요하지 않은지 설명해주실 수 있을까요?
JPA는 주로 복잡한 관계형 데이터 모델을 가진 애플리케이션 개발에 사용됩니다.
이를 통해 개발자는 데이터베이스 작업 을 객체 지향적으로 처리할 수 있으며, CRUD 작업을 간소화할 수 있습니다.
또한, 다양한 데이터베이스 제품과의 호환성을 제공하여 데이터베이스 독립성을 보장하고, 내장된 캐싱, 페이징, 트랜잭션 관리 기능을 통해 개발 및 유지보수 효율을 높일 수 있습니다.
그러나, 프로젝트가 단순한 데이터 모델을 가지고 있거나 높은 성능을 요구하는 경우, JPA는 필요하지 않을 수 있습니다.
이런 상황에서는 JPA의 오버헤드가 부담이 될 수 있으며, 직접 SQL을 사용하거나 더 경량화된 데이터 액세스 기술을 고려하 는 것이 나을 수 있습니다.
또한, NoSQL 데이터베이스를 사용하는 경우 JPA는 적합하지 않으며, 해당 데이터베이스 유형에 맞는 기술을 선택해야 합니다.
요약하자면, JPA는 복잡한 데이터 관계와 효율적인 개발이 중요한 경우 유용하지만, 프로젝트의 구체적인 요구사항과 기술적 맥락을 고려하여 적합한 데이터 액세스 방식을 결정해야 합니다.
JPA의 더티 체킹이란 무엇인가요?
더티 체킹은 JPA의 핵심 기능 중 하나로, 애플리케이션의 엔티티 객체가 변경된 후 트랜잭션이 종료될 때, 변경된 내용을 자동으로 데이터베이스에 반영하는 메커니즘입니다.
JPA는 엔티티 매니저(entity manager)를 통해 엔티티 객체를 관리하며, 각 트랜잭션 시작 시 엔티티의 초기 상태를 스냅샷으로 저장합니다.
트랜잭션이 종료되기 전, 엔티티 매니저는 스냅샷과 현재 엔티티 객체의 상태를 비교하여 변화가 있는 경우, 해당 변화를 SQL 업데이트 문으로 변환하여 데이터베이스에 반영합니다.
더티 체킹 덕분에 개발자는 엔티티 객체의 상태를 명시적으로 업데이트하지 않아도 되며, 이는 코드의 양을 줄이고, 버그 발생 가능성을 낮추는 데 도움이 됩니다.
또한, 이 기능은 JPA의 트랜잭션 관리와 밀접하게 연관되어 있어, 애플리케이션의 데이터 일관성을 유지하는 데 중요한 역할을 합니다.
JVM 이란 무엇이고 왜 필요한지 설명해주실 수 있을까요?
JVM은 자바 애플리케이션의 실행을 위한 핵심 컴포넌트로, 자바의 '한 번 작성하면 어디서나 실행(WORA, Write Once, Run Anywhere)'라는 철학을 실현합니다.
바이트코드 형태로 컴파일된 자바 애플리케이션은 JVM을 통해 다양한 운영 체제에서 실행될 수 있습니다.
이는 JVM이 운영 체제와 자바 애플리케이션 사이의 중개자 역할을 하기 때문입니다.
JVM의 중요한 기능 중 하나는 가비지 컬렉션(Garbage Collection)입니다.
이 기능은 더 이상 사용되지 않는 메모리 자원을 자동으로 회수하여 메모리 관리를 단순화합니다.
또한, JVM은 메모리 관리, 멀티스레딩 지원, 보안 관리 등과 같은 다양한 기능을 제공하여 애플리케이션의 안정적인 실행을 돕습니다.
결론적으로, JVM은 자바 애플리케이션의 플랫폼 독립성을 보장하고, 개발자가 메모리 관리와 같은 복잡한 시스템 수준의 작업에 대해 걱정하지 않도록 하여, 애플리케이션의 효율적인 개발과 안정적인 운영을 지원합니다.
Java가 컴파일 되는 과정은 어떻게 되는지 설명해주실 수 있을까요?
Java의 컴파일 과정은 크게 네 단계로 이루어집니다.
1. 소스 코드 작성: 개발자는 .java 확장자를 가진 파일에 Java 언어 규칙에 따라 소스 코드를 작성합니다.
2. 컴파일: Java 컴파일러(javac)는 .java 파일을 읽어들여 문법적 오류를 검사하고, 올바른 경우 바이트코드를 포함한 .class 파일을 생성합니다. 이 바이트코드는 JVM이 이해할 수 있는 중간 형태의 코드입니다.
3. 로딩: JVM은 .class 파일을 로드(load)하여 메모리에 적재합니다. 이 과정에서 클래스 로더(Class Loader)가 사용되며, 필요한 클래스들을 동적으로 메모리에 로딩합니다.
4.실행: 로드된 클래스 파일들은 실행 엔진(Execution Engine)에 의해 해석되고 실행됩니다. 실행 엔진은 바이트코드를 한 줄씩 읽어서 기계어로 변환(Just-In-Time 컴파일)하거나 직접 해석하여 실행합니다.
이 과정을 통해 Java 소스 코드는 먼저 플랫폼 독립적인 바이트코드로 변환되고, 이후 필요에 따라 JVM이 설치된 어떠한 시스템에서도 실행될 수 있습니다.
이러한 컴파일 과정은 Java가 '한 번 작성하면 어디서나 실행(WORA)'을 가능하게 하는 핵심 요소입니다.
JVM의 스택과 힙 메모리 영역에 대해 아는 만큼 설명해주실 수 있을까요?
스택 메모리 영역: 스택 메모리는 각 스레드별로 존재하며, 메서드 호출과 로컬 변수 저장에 사용됩니다.
스택은 후입선출(LIFO, Last In First Out) 구조를 가지며, 메서드가 호출될 때마다 메서드에 대한 스택 프레임이 생성됩니다. 스택 프레임은 로컬 변수, 연산 중간 결과, 메서드 호출과 리턴에 대한 정보를 포함합니다.
메서드가 종료되면 해당 스택 프레임은 스택에서 제거됩니다.
스택 메모리는 상대적으로 관리가 단순하고 접근 속도가 빠르지만, 크기가 고정되어 있으므로 오버플로우(스택 메모리 부족)가 발생할 수 있습니다.
힙 메모리 영역: 힙 메모리는 애플리케이션 전체에서 공유되는 영역으로, 객체와 배열과 같은 동적으로 할당된 데이터를 저장하는 데 사용됩니다.
힙은 스레드 간 공유되며, JVM의 가비지 컬렉터에 의해 관리됩니다.
객체가 생성되면 힙에 메모리가 할당되고, 더 이상 참조되지 않는 객체는 가비지 컬렉터에 의해 자동으로 회수됩니다.
힙 메모리는 런타임에 동적으로 확장될 수 있지만, 메모리 관리가 복잡하고 접근 속도가 스택에 비해 상대적으로 느립니다.
스택과 힙 메모리의 이해는 자바 애플리케이션의 성능 최적화와 메모리 관리에 중요합니다.
스택은 각 스레드의 메서드 호출 및 로컬 변수 처리에, 힙은 애플리케이션의 객체와 배열 저장에 사용되어, 자바 애플리케이션의 메모리 구조와 생명 주기를 결정합니다.
'항해 99' 카테고리의 다른 글
WIL-10 (1) | 2024.04.14 |
---|---|
기술면접 준비 2주차 정리 (0) | 2024.04.13 |
WIL-9 (0) | 2024.04.07 |
Git Project 관리 (0) | 2024.04.01 |
WIL-8 (0) | 2024.03.31 |