[Java] 코드로 시작하는 자바 첫 걸음 (4-6) Q & A

💡 inflearn - 김영한의 실전 자바 로드맵을 따라 학습하고 질문을 뽑아 답하며 복습합니다.

💡 학습내용은 섹션 4부터 섹션6까지이며 정리 내용은 여기에 작성하였습니다.

 

연산자

 

"문자열을 비교할 때 == 대신 equals()를 사용해야 하는 이유를 설명해주세요."

• == 연산자는 객체의 참조(메모리 주소)를 비교하고, equals()는 객체의 내용을 비교합니다.
• String 객체는 생성 방식에 따라 다르게 동작합니다:
  • 리터럴로 생성 시("hello"): String Pool에 저장되어 같은 문자열은 같은 참조를 공유합니다.
  • new 연산자로 생성 시: 항상 새로운 객체가 생성되어 다른 참조를 가지게 됩니다.

    String str1 = "hello";
    String str2 = "hello";
    String str3 = new String("hello");
    str1 == str2; // true (같은 String Pool의 참조)
    str1 == str3; // false (다른 객체 참조)
    str1.equals(str3); // true (내용 비교)

 

"산술 연산에서 발생할 수 있는 예외 상황에는 어떤 것들이 있나요? (예: 0으로 나누기)"

• 0으로 나누기: ArithmeticException 발생할 수 있습니다.
  • 이를 방지하기 위해선 사전에 분모 체크가 필요합니다.
• 정수 오버플로우/언더플로우: 타입의 범위를 넘어서는 계산 시 발생할 수 있습니다.
  • 상황에 따라 더 큰 데이터 타입을 사용하여 방지합니다.
• 부동 소수점 연산의 정밀도 문제: 0.1 + 0.2 != 0.3
  • BigDecimal 클래스를 사용합니다.

 

"BigDecimal 클래스를 사용하는 이유는 뭔가요?"

• 자바에서 실수형(float, double)은 부동소수점 방식을 사용하기 때문에 정확한 실수 계산이 어렵습니다.
• BigDecimal은 이런 부동소수점의 오차 없이 정확한 실수 계산이 가능합니다.
• 다만 BigDecimal은 일반 실수형보다 연산 속도가 느리고 메모리를 더 사용하는 단점이 있어, 정확한 계산이 필요한 경우에만 선택적으로 사용합니다.

 

 

"증감 연산자(++, --)의 전위 연산과 후위 연산의 차이점을 예제와 함께 설명해주세요."

• 증감 연산자를 변수 앞에 붙이면 전위 연산, 뒤에 붙이면 후위 연산으로 부릅니다.

    int a = 1;
    int b = ++a;
    int c = a++;

  위 코드를 놓고 설명드리겠습니다. 정수 변수 a가 있고 a의 값은 1으로 가정했을 때 전위 연산의 경우 ++a로 나타냅니다. 그리고 이 경우 같은 라인의 코드가 존재할 때 전위 연산을 먼저 실행한 뒤에 같은 라인의 코드를 실행 합니다. 예를 들어 int b = ++a 의 코드는 b에 값을 담기 전에 a = a + 1을 먼저 실행하게 됩니다. 그래서 b에는 2가 저장됩니다. 반대로 int c = a++의 경우 같은 라인의 코드에서 후위 연산을 가장 나중에 실행하게 됩니다. c에는 연산 전의 a값인 2가 저장되고 그 뒤에 a = a + 1이 진행됩니다.

 

 

조건문

 

"if-else와 switch 중 어떤 상황에서 어떤 것을 선택해야 할까요?"

• 상황에 따라 다르다고 말씀드릴 수 있습니다. 단순 값으로만 조건으로 판별할 경우, 아니면 조건으로 인한 값에 따라 변수에 변경된 값을 저장해야 하는 경우 switch문이 가독성과 유지보수성이 나을 수 있습니다. 조건식이 단순 값으로 분류될 수 없거나 조건식 내에 연산식이 포함될 경우 if-else문이 나을 수 있습니다.

 

 

"switch 문에서 break를 사용하지 않으면 어떤 일이 발생하나요? 이를 활용할 수 있는 경우를 설명해주세요."

• switch에 break를 사용하지 않을 경우 다음 조건문도 비교를 할 수 있습니다. 이 경우 동일한 값을 반환하거나 메서드를 호출해야 하는 경우 break를 사용하여 불필요한 연산을 하지 않도록 할 수 있습니다.

 

 

"삼항 연산자는 어떤 상황에서 사용하면 좋을까요? if-else와 비교했을 때 장단점은?"

• 단순 trueor false만 판별하여 변수에 값을 담거나 메서드를 호출해야 할 때 사용하면 좋습니다. 장단점은 if-else에 비해 라인 수를 줄일 수 있다는 장점이 있으나 오히려 이 점으로 인해 가독성이 나빠질 수 있다는 단점도 존재합니다.

 

 

반복문

 

"for문과 while문의 차이점을 설명하고, 각각 어떤 상황에서 사용하면 좋은지 설명해주세요."

• for문의 경우 초기식, 반복 횟수, 반복 조건 식이 존재하여 반복횟수를 일정한 수로 제한 할 수 있습니다. while도 변수와 break를 이용하여for문 처럼 제한된 반복문을 설정할 수 있지만 조건을 걸지 않고 무한루프도 가능합니다. 횟수의 제한이 없고 프로그램이 계속 실행되어야 할 경우에는 while을 사용하는 것이 낫고 횟수의 제한이 필요하고 일정 횟수 안으로는 프로그램이 종료되어야 하는 경우 for를 사용하는 것이 낫습니다.

 

 

"break와 continue의 차이점을 설명하고, 각각의 사용 예시를 들어주세요."

• break는 반복문을 종료하고 빠져나오게 하는 키워드이며 continue는 반복문을 종료하지 않고 continue 이후의 코드는 실행하지 않고 다시 조건식으로 이동하여 다음 회차의 반복문을 실행하도록 합니다. 실생활에서도 그 예를 접할 수 있는데 윈도우 os 환경에서 파일 리스트를 어떤 폴더에 복사-붙여넣기 할 때 동일한 파일 리스트가 있어 화면에 노출되는 알림창을 보신 적 있을 겁니다. 그 알림 창에서 건너뛰기 버튼은 continue이고 중지버튼은 break라고 볼 수 있습니다. 덮어쓰기버튼의 경우 continue이후의 코드라고 생각할 수 있습니다.

 

 

"무한 루프는 어떤 상황에서 사용될 수 있으며, 이를 안전하게 사용하는 방법은 무엇인가요?"

• 서버 프로그램의 메인 루프, 사용자 입력 대기, 메시지 큐 처리 등의 상황이 있을 수 있습니다.
• 안전하게 사용하는 방법으론:
  • 명확한 종료 조건 구현 (break 조건)
  • timeout 설정으로 무한 대기 방지
  • 리소스 모니터링 및 관리
  • 주기적인 상태 체크
  • try-catch로 예외 상황 처리
    이 있습니다.

 

 

성능과 최적화

 

"반복문에서 성능 최적화를 위해 고려해야 할 사항들은 무엇인가요?"

• 반복문 내부에서:
  • 객체 생성을 최소화합니다.
  • 불변 값은 반복문 외부로 이동시킵니다.
  • Collection 접근 시 적절한 자료구조 선택합니다.

 

"switch 문과 if-else 문의 성능 차이가 발생하는 원인과 JVM의 최적화 방식을 설명해주세요."

• switch문은 jump table을 사용하여 O(1) 시간 복잡도로 분기를 처리합니다.
• if-else는 조건을 순차적으로 평가하므로 O(n) 시간 복잡도를 갖습니다.
• 따라서 분기가 많은 경우 switch문이 더 효율적일 수 있습니다.

 

 

"jump table 이 무엇인지 설명해주세요."

• jump table(점프 테이블)은 switch 문을 최적화하기 위해 컴파일러가 생성하는 자료구조입니다.
• 작동 방식

// 이런 switch문이 있다고 가정합니다.
switch (value) {
    case 1: return "ONE";
    case 2: return "TWO";
    case 3: return "THREE";
}

// 컴파일러는 내부적으로 이런 점프 테이블을 생성합니다.
// address[1] -> code for case 1
// address[2] -> code for case 2
// address[3] -> code for case 3

• O(1) 시간 복잡도: value 값으로 바로 해당 case의 주소를 찾아갈 수 있음
• if-else와 달리 조건을 순차적으로 확인할 필요가 없음

 

 

"String 연산에서 + 연산자 대신 StringBuilder를 사용해야 하는 이유를 JVM 메모리 관리 관점에서 설명해주세요."

• String은 불변(immutable) 객체라 + 연산마다 새로운 String 객체가 힙 메모리에 생성되고 기존 String 객체는 가비지 컬렉션 대상이 됩니다.
• StringBuilder는 가변(mutable) 객체라 동일 객체 내에서 문자열을 조작합니다.
  • 내부적으로 가변 크기의 char[] 배열을 사용하고 있습니다.
  • append() 시 필요한 경우에만 배열 크기를 조정합니다.
  • 하나의 객체 내에서 문자열 조작이 이루어져 추가 객체 생성이 없습니다.
• 예시:

  String str = "a" + "b" + "c"; // 내부적으로 여러 String 객체 생성
  StringBuilder sb = new StringBuilder()
      .append("a").append("b").append("c"); // 하나의 객체만 사용

• 정리하자면 String + 연산의 경우 중간 객체들의 생성과 GC로 인한 메모리 부하가 발생할 수 있고, StringBuilder의 경우 단일 객체 사용으로 메모리를 효율적으로 관리할 수 있어 StringBuilder를 사용해야 합니다.

 

 

"반복문 내에서 문자열 연산이 많을 때 발생할 수 있는 문제점과 해결 방안은?"

• 문자열을 + 연산자로 계속 연결하면 매번 새로운 String 객체가 생성되어 메모리 낭비가 발생할 수 있습니다.
  • 해결방안으로는 StringBuilder를 사용하여 문자열을 연결하면 됩니다.

 

"무한 루프가 발생했을 때 디버깅하고 해결하는 절차를 설명해주세요."

• 문제 파악 단계에서는:
  • 로그를 통한 반복 횟수와 주요 변수 값을 모니터링합니다.
  • 디버거를 통한 변수 값 변화를 추적합니다.
• 문제 파악 이후로는:
  • 반복문의 종료 조건이 제대로 설정되어 있는지 확인합니다.
  • 종료 조건에 사용되는 변수가 적절히 변경되고 있는지 체크합니다.
  • 필요하다면 최대 실행 횟수나 timeout을 설정하여 안전장치를 추가합니다.

 

"대용량 데이터를 처리하는 반복문을 작성할 때 주의해야 할 점은?"

• 메모리 사용량을 고려해야 합니다. 한 번에 너무 많은 데이터를 처리하지 않도록 합니다.
• 불필요한 객체 생성을 최소화합니다.
• 가능하다면 처리 데이터를 분할하여 batch 처리하는 것이 좋습니다.

 

 

설계와 구현 패턴

 

"switch 문을 사용한 코드를 OOP 관점에서 개선하는 방법을 설명해주세요. (Strategy 패턴 등)"

// Before: switch 문 사용
public class PaymentProcessor {
    public void processPayment(String type) {
        switch (type) {
            case "CREDIT":
                processCreditPayment();
                break;
            case "DEBIT":
                processDebitPayment();
                break;
            case "KAKAO":
                processKakaoPayment();
                break;
        }
    }
}

1. Strategy 패턴

// After: Strategy 패턴 적용
interface PaymentStrategy {
    void process();
}

class CreditPayment implements PaymentStrategy {
    public void process() {
        // 신용카드 결제 처리
    }
}

class DebitPayment implements PaymentStrategy {
    public void process() {
        // 직불카드 결제 처리
    }
}

class KakaoPayment implements PaymentStrategy {
    public void process() {
        // 카카오페이 결제 처리
    }
}

class PaymentProcessor {
    private final Map<String, PaymentStrategy> strategies = new HashMap<>();

    public PaymentProcessor() {
        strategies.put("CREDIT", new CreditPayment());
        strategies.put("DEBIT", new DebitPayment());
        strategies.put("KAKAO", new KakaoPayment());
    }

    public void processPayment(String type) {
        PaymentStrategy strategy = strategies.get(type);
        strategy.process();
    }
}

1. 새로운 타입 추가가 용이합니다. (OCP - Open-Closed Principle)
    - 새로운 결제 방식 추가 시 새로운 클래스만 구현하면 됩니다.
    - 기존 코드 수정이 불필요합니다.
2. 각 처리 로직을 별도 클래스로 분리하였습니다. (SRP - Single Responsibility Principle)
    - 각 결제 방식별 로직을 독립적으로 관리할 수 있습니다.
    - 코드의 응집도가 높아지고 결합도가 낮아지는 효과를 얻습니다.
3. 실행 시점에 전략을 변경할 수 있습니다. (유연성 증가)
    - 런타임에 다른 결제 방식으로 교체가 가능합니다.

 

 

"반복문 처리 시 발생할 수 있는 교착 상태(deadlock)를 방지하기 위한 설계 방법을 설명해주세요."

• 모르겠습니다..!
• 자원 할당 순서 일관성 유지
  • Lock Ordering 기법을 사용하여 자원을 항상 일정한 순서로 획득하도록 합니다. 이는 순환 대기 조건을 방지하여 교착 상태를 예방합니다. 예를 들어, 여러 개의 락을 사용해야 할 경우 항상 낮은 번호의 락부터 높은 번호의 락 순으로 획득하도록 합니다.
• 타임아웃 및 재시도 메커니즘 구현
  • 자원 획득 시 타임아웃을 설정하고, 일정 시간 내에 자원을 획득하지 못하면 작업을 중단하고 나중에 재시도하도록 합니다. 이 방법은 무한정 대기하는 상황을 방지하여 교착 상태를 회피할 수 있습니다.
• 자원 할당 그래프 활용
  • Resource Allocation Graph를 사용하여 자원 할당 상태를 모니터링하고 순환 대기 조건이 발생하지 않도록 관리합니다. 이 방법을 통해 잠재적인 교착 상태를 사전에 감지하고 예방할 수 있습니다.
• 점유와 대기 조건 방지
  • 프로세스가 필요한 모든 자원을 한 번에 요청하도록 설계합니다. 이렇게 하면 일부 자원만 보유한 채 다른 자원을 기다리는 상황을 방지할 수 있습니다. 다만, 이 방법은 자원 활용도가 낮아질 수 있다는 단점이 있습니다.
• 비선점 조건 완화
  • 우선순위가 높은 프로세스가 필요한 자원을 선점할 수 있도록 허용합니다. 이를 통해 교착 상태에 빠질 가능성을 줄일 수 있지만, 프로세스 간 자원 해제와 재획득이 빈번하게 발생할 수 있습니다.
• 고급 동시성 메커니즘 활용
  • 락 프리(lock-free) 데이터 구조나 트랜잭션 메모리와 같은 고급 동시성 메커니즘을 사용하여 복잡한 동시성 제어를 단순화하고 교착 상태 발생 가능성을 줄입니다.이러한 방법들을 적절히 조합하여 사용하면 반복문 처리 시 발생할 수 있는 교착 상태를 효과적으로 방지할 수 있습니다. 또한, 시스템의 특성과 요구사항에 맞는 최적의 방법을 선택하는 것이 중요합니다.

 

"여러 개의 중첩된 if-else 문을 어떻게 리팩토링하면 좋을까요?"

• 조건의 복잡도를 줄이기 위해:
  1. guard clause 패턴 적용 (early return) 합니다.
  2. 복잡한 조건을 의미 있는 메서드로 분리합니다.
  3. 공통 조건을 상위로 추출하여 처리합니다.
  4. 조건을 단순화할 수 있는 열거형(enum) 활용합니다.
  5. 가능한 경우 switch문 사용을 고려합니다.

 

"반복문과 조건문이 많은 코드를 리뷰할 때 주로 어떤 점들을 체크하시나요?"

• 중복되는 연산이 있는지 확인합니다.
• 불필요한 중첩이 있는지 확인합니다.
• 반복문의 종료 조건이 명확한지 확인합니다.
• 조건문의 순서가 최적화되어 있는지 확인합니다(자주 발생하는 조건을 먼저 체크).

 

 

JVM과 내부 동작

 

"JVM이 switch 문을 컴파일할 때 내부적으로 어떤 최적화를 수행하는지 설명해주세요."

• 모르겠습니다..!

테이블스위치(tableswitch)와 룩업스위치(lookupswitch)

JVM은 switch 문을 두 가지 바이트코드 중 하나로 컴파일합니다

1. 테이블스위치(tableswitch): case 값들이 서로 가까운 경우 사용됩니다. 이는 더 빠른 실행을 제공합니다.
2. 룩업스위치(lookupswitch): case 값들이 서로 멀리 떨어져 있는 경우 사용됩니다.

예를 들어:

switch (value) {
    case 1 -> "one";
    case 2 -> "two";
    case 4 -> "four";
    default -> "other";
}

위 코드는 테이블스위치로 컴파일됩니다.

switch (value) {
    case 1 -> "one";
    case 10 -> "ten";
    case 100 -> "one hundred";
    default -> "other";
}

위 코드는 룩업스위치로 컴파일됩니다.

 

점프 테이블 최적화

컴파일러는 switch 문을 점프 테이블로 변환하여 직접 해당 case로 이동할 수 있게 합니다. 이는 if-else 문보다 더 효율적인 실행을 가능하게 합니다.

 

런타임 최적화

1. HotSpot JVM 최적화
   • HotSpot JVM은 실행 시간에 다양한 최적화를 수행합니다.
     • 인라이닝: 자주 호출되는 switch 문을 포함한 메서드를 인라인화하여 성능을 향상시킵니다.
     • 루프 최적화: switch 문이 루프 내에 있는 경우, 루프 언롤링, 벡터화 등의 기법을 적용합니다.
     • 분기 예측: 자주 실행되는 case를 예측하여 실행 속도를 높입니다.
2. 동적 최적화
   • JIT(Just-In-Time) 컴파일러는 실행 중에 switch 문의 패턴을 분석하고 최적화합니다.
     • 프로파일 기반 최적화: 자주 실행되는 case를 먼저 검사하도록 재정렬합니다.
     • 스위치 분석: 복잡한 switch 문을 더 효율적인 형태로 변환합니다.
3. 이스케이프 분석
   • JVM은 이스케이프 분석을 통해 switch 문 내에서 생성된 객체가 메서드를 벗어나지 않는 경우, 해당 객체의 할당을 제거하거나 스택에 할당하는 최적화를 수행할 수 있습니다.이러한 최적화 기법들을 통해 JVM은 switch 문의 성능을 크게 향상시킬 수 있습니다. 그러나 대부분의 경우 개발자는 가독성과 유지보수성을 우선으로 고려하고, 극단적인 성능 최적화가 필요한 경우에만 이러한 내부 동작을 고려하는 것이 좋습니다.

 

"String equals() 메소드의 내부 구현을 설명하고, 성능 최적화를 위해 고려해야 할 사항들을 설명해주세요."

• "String equals() 메소드의 내부 구현"
  1. 문자열 전체를 비교하기 전에 수행하는 빠르게 검사합니다.
     • 동일 객체 참조인지 확인 (this == obj)
     • null 체크
  2. 문자열을 비교합니다.
     • 길이 비교
     • 문자 배열을 순차적으로 비교
• 성능 최적화 방안:
  • 자주 사용되는 문자열은 String Pool 활용
  • 불필요한 String 객체 생성 최소화

"String Pool에 대해 설명해주세요."

• String Pool(또는 String Constant Pool)은 자바의 특별한 메모리 영역으로, 문자열 리터럴을 저장하고 재사용하기 위한 공간입니다.
  • 작동 방식
    1. 문자열 리터럴을 생성할 때(예: String str = "hello"), JVM은 먼저 String Pool에서 동일한 문자열을 찾습니다.
    2. 동일한 문자열이 있으면 그 참조를 반환합니다.
    3. 없으면 String Pool에 새로 생성하고 그 참조를 반환합니다.
  • String Pool의 장점
    • 메모리 효율성: 동일한 문자열을 여러 번 생성하지 않음
    • 성능 향상: 문자열 비교 시 객체 재사용으로 인한 이점

"반복문 실행 시 JVM의 JIT 컴파일러는 어떤 최적화를 수행하나요?"

• 모르겠습니다..!
• 루프 언롤링 (Loop Unrolling)
  • 루프 언롤링은 반복문의 본문을 여러 번 복사하여 펼치는 기법입니다.
  • 이점
    • 반복 횟수 감소로 인한 분기 예측 실패 감소
    • 명령어 파이프라인 최적화
    • 명령어 수준 병렬성 향상

다음과 같은 코드를

for(int i = 0; i < numIterations; i++) {
    METRICS.gauge("test.metric", i);
}

아래와 같이 변환할 수 있습니다.

for(int i = 0; i < numIterations; i += 5) {
    METRICS.gauge("test.metric", i);
    METRICS.gauge("test.metric", i+1);
    METRICS.gauge("test.metric", i+2);
    METRICS.gauge("test.metric", i+3);
    METRICS.gauge("test.metric", i+4);
}

• 범위 검사 제거 (Range Check Elimination)
  • JIT 컴파일러는 배열 접근 시 범위를 벗어나지 않는다고 판단되면 범위 검사를 제거합니다.

예를 들어, 다음과 같은 코드에서 컴파일러는 i가 항상 arr.length 미만임을 보장할 수 있으므로 배열 접근 시 범위 검사를 생략할 수 있습니다.

for(int i = 0; i < arr.length; i++) {
    System.out.println(arr[i]);
}

• 루프 변환 (Loop Transformation)
  • JIT 컴파일러는 long 타입의 반복문을 int 타입의 중첩 반복문으로 변환하여 기존의 int 기반 최적화를 적용할 수 있게 합니다.
• 루프 불변 코드 이동 (Loop-Invariant Code Motion)
  • 반복문 내에서 변하지 않는 연산을 반복문 밖으로 이동시켜 불필요한 계산을 줄입니다.
• 루프 분리 (Loop Unswitching)
  • 조건문을 포함한 루프를 조건에 따라 두 개의 별도 루프로 분리하여 분기 예측을 개선합니다.
• 벡터화 (Vectorization)
  • SIMD (Single Instruction, Multiple Data) 명령어를 사용하여 여러 데이터를 동시에 처리합니다.이러한 최적화 기법들은 JIT 컴파일러가 실행 시간에 코드의 실행 패턴을 분석하고, "핫스팟"으로 판단되는 부분에 적용됩니다. 이를 통해 Java 프로그램의 전반적인 성능을 크게 향상시킬 수 있습니다.

 

팀 협업 관련

 

"주니어 개발자가 작성한 복잡한 조건문을 리뷰할 때, 어떤 방식으로 피드백하시나요?"

• 조건문에 대핸 리뷰 경험은 없으나 아래 방식으로 진행하겠습니다.
  • 리팩토링이 필요한 부분을 예시 코드와 함께 설명합니다.
  • 성능이나 가독성 측면에서 개선 가능한 부분을 제안합니다.
  • 왜 그렇게 개선해야 하는지 이유를 설명합니다.
  • 관련 디자인 패턴이나 베스트 프랙티스를 공유합니다.

 

"팀에서 통일된 코드 스타일을 위해 조건문/반복문 작성 시 어떤 규칙을 만들어 보셨나요?"

• 조건문 및 반복문에 대한 규칙이 따로 없었으나 만든다면 이렇게 세우겠습니다.
  • 조건문
    • 복잡한 조건은 별도 메서드로 추출
    • early return 패턴 사용
  • 반복문
    • 중첩 반복문은 최대 2단계까지만 허용
    • 반복문 내 로직은 별도 메서드로 분리