week 5 incheol - GANGNAM-JAVA/JAVA-STUDY GitHub Wiki

JAVA (박효원)

• 해시맵 충돌 해결방법(확인필요)

  hashcode % M 을 통해서 버킷의 크기보다 작은 인덱스에 저장을 하도록 한다. 따라서 1/M확률로 충돌이 발생하게 된다. 해시맵 충돌 해결할 수 있는 방법으로는 대표적으로 두 가지 방법이 있다.

  Open Addressing은 데이터를 삽입하려는 해시 버킷이 이미 사용 중인 경우 다른 해시 버킷에 해당 데이터를 삽입하는 방식이다.

  Separate Chaining에서 각 배열의 인자는 인덱스가 같은 해시 버킷을 연결한 링크드 리스트의 첫 부분(head)이다.

  Java HashMap에서 사용하는 방식은 Separate Channing이다. Open Addressing은 데이터를 삭제할 때 처리가 효율적이기 어려운데, HashMap에서 remove() 메서드는 매우 빈번하게 호출될 수 있기 때문이다. 게다가 HashMap에 저장된 키-값 쌍 개수가 일정 개수 이상으로 많아지면, 일반적으로 Open Addressing은 Separate Chaining보다 느리다. Open Addressing의 경우 해시 버킷을 채운 밀도가 높아질수록 Worst Case 발생 빈도가 더 높아지기 때문이다. 반면 Separate Chaining 방식의 경우 해시 충돌이 잘 발생하지 않도록 '조정'할 수 있다면 Worst Case 또는 Worst Case에 가까운 일이 발생하는 것을 줄일 수 있다(여기에 대해서는 "보조 해시 함수"에서 설명하겠다).

  Java 8 HashMap에서는 Entry 클래스 대신 Node 클래스를 사용한다. Node 클래스 자체는 사실상 Java 7의 Entry 클래스와 내용이 같지만, 링크드 리스트 대신 트리를 사용할 수 있도록 하위 클래스인 TreeNode가 있다는 것이 Java 7 HashMap과 다르다.

  데이터의 개수가 많아지면, Separate Chaining에서 링크드 리스트 대신 트리를 사용하기 때문이다.

  8과 6으로 2 이상의 차이를 둔 것은, 만약 차이가 1이라면 어떤 한 키-값 쌍이 반복되어 삽입/삭제되는 경우 불필요하게 트리와 링크드 리스트를 변경하는 일이 반복되어 성능 저하가 발생할 수 있기 때문이다.

• thread safe란? 해결/회피 방법?

  • java.util.concurrent 패키지에는 멀티 스레드 환경에서 데이터의 원자성을 보장하기 위한 API를 확인 해볼 수 있다.

    • synchronized

      public synchronized void 메소드 () { 
          내용... 
      } 
      
      public void 메소드 () { 
          내용... 
          synchronized (this) { 동기화내용... } 
      }

    • ReentrantLock

      기존의 synchronized는 이렇게 메소드전체나 구간을 묶어서 동기화를 시켰습니다.

      그런데 ReentrantLock 클래스를 사용하면 조금은 번거롭더라도 시작점과 끝점을 명백히 명시할 수 있습니다.

      class SomeClass { 
          private final ReentrantLock locker = new ReentrantLock(); 
          public void SomeMethod () { 
              locker.lock(); 
              // 쓰레드에 락을 겁니다.(동기화의 시작) 
              try { 동기화내용들... } 
              catch (어떤예외들) { 해당예외처리... } 
              finally { 
                  locker.unlock(); // 쓰레드의 락을 풉니다.(동기화 끝지점) 
              } 
          } 
      }

    • AtomicInteger

      public class AtomicInteger extends Number implements java.io.Serializable { 
          private volatile int value; public final int incrementAndGet() { 
              int current; 
              int next; 
              do { 
                  current = get(); next = current + 1; 
              } 
              while (!compareAndSet(current, next)); 
              
              return next; 
          } 
              
          public final boolean compareAndSet(int expect, int update) { 
              return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 
          } 
      }

      다른 AtomicInteger 메소드 들도 거의 유사한 패턴으로 구현되어 있다. 또한 눈여겨 볼 점은 volatile int value; 선언부 인데 voliatile는 변수의 가시성 문제를 해결하기 위해서 사용된다. volatile 키워드가 붙어 있는 객체는 CPU캐시가 아닌 메인 메모리에서 값을 참조해온다. 그렇다면 굳이 CAS알고리즘을 적용하지 않아도 문제가 없는 것 아닐까? 그렇지 않다. volatile 키워드는 오직 한개의 쓰레드에서 쓰기작업을 할 때, 그리고 다른 쓰레드는 읽기 작업만 할 때 안정성을 보장한다. 그런데 AtomicIntger는 여러 쓰레드에서 읽기/쓰기 작업을 병행한다. 그래서 CAS알고리즘이라는 2중의 안정장치를 설치해 놓은 것이다.

  • 회피

    • 데이터 불변성 확보 : 모든 필드를 final로 선언
    • 데이터 사본을 활용 : Collections.unmodifiableList(list);
    • Compare and Swap(CAS) 를 사용하라 : Synchronized와 같은 명시적 Lock을 사용하기 보다 CAS를 사용하는 것이 성능향상에 도움을 준다. Low Level의 Atomic 전략에 해당한다. java.util.concurrent.atomic 패키지에는 CAS를 적용한 메소드가 많이 있다.

SPRING (유정현)

• n+1 쿼리 문제란?

  • Join 관계에서 발생하는 이슈로 join된 모델을 읽을 때 하나의 쿼리로 데이터를 읽어오는게 아닌 쿼리에서 만들어진 데이터의 갯수(n)만큼 select 쿼리를 추가로 발생하여 데이터를 읽어오게 된다.
  • fetch.eager 에서 fetch.lazy 을 변경한다고 해서 쿼리를 수행하는 시점이 변경될 뿐이지 실행되는 쿼리의 갯수는 변함이 없다.
  • 원인 : jpaRepository에 정의한 인터페이스 메서드를 실행하면 JPA는 메서드 이름을 분석해서 JPQL을 생성하여 실행하게 된다. JPQL은 SQL을 추상화한 객체지향 쿼리 언어로서 특정 SQL에 종속되지 않고 엔티티 객체와 필드 이름을 가지고 쿼리를 한다.
  • 해결방안

    • fetch join - inner join : 직접 쿼리 메소드에 사용할 JPQL을 명시해주면서 fetch 키워드를 추가해준다. (페이징 api를 사용할 수 없다)

    • FetchMode.SUBSELECT

      연관된 데이터를 조회할 때 서브쿼리를 사용해서 N+1 문제를 해결한다

      @Entity
      class Member{
          @Id @GeneratedValue
          private Long id;
      
          @org.hibernate.annotations.Fetch(FetchMode.SUBSELECT)
          @OneToMany(mappedBy = "member", fetch = FetchType.EAGER)
          private List<Order> orders = new ArrayList<>();
      }

      아래와 같이 실행된다.

      SELECT * FROM Member;
      SELECT * FROM Order_
          WHERE MEMBER_ID IN(
              SELECT ID
              FROM Member
          )

      즉시로딩으로 설정하면 조회시점에, 지연로딩으로 설정하면 지연로딩된 엔티티를 사용하는 시점에 위의 쿼리가 실행된다.

      모두 지연로딩으로 설정하고 성능 최적화가 필요한 곳에는 JPQL 페치 조인을 사용하는 것이 추천되는 전략이다.

    • EntityGraph - left outer join : @EntityGraph 의 attributePaths에 쿼리 수행시 바로 가져올 필드명을 지정하면 Lazy가 아닌 Eager 조회로 가져오게 된다.

      • 공통적으로 카테시안 곱(Cartesian Product)이 발생하여 Subject의 수만큼 Academy가 중복 발생하게
      • Set은 중복을 허용하지 않는 자료구조이기 때문에 중복등록이 되지 않습니다
      • 2번째 방법은 distinct를 사용하여 중복을 제거하는 것입니다

    • BatchSize

      하이버네이트가 제공하는 org.hibernate.annotations.BatchSize 어노테이션을 이용하면 연관된 엔티티를 조회할 때 지정된 size 만큼 SQL의 IN절을 사용해서 조회한다.

      @Entity
      class Member{
          @Id @GeneratedValue
          private Long id;
      
          @org.hibernate.annotations.BatchSize(size = 5)
          @OneToMany(mappedBy = "member", fetch = FetchType.EAGER)
          private List<Order> orders = new ArrayList<>();
      }

      즉시로딩이므로 Member를 조회하는 시점에 Order를 같이 조회한다.@BatchSize가 있으므로 Member의 건수만큼 추가 SQL을 날리지 않고, 조회한 Member 의 id들을 모아서 SQL IN 절을 날린다.

      SELECT * FROM
      ORDER_ WHERE MEMBER_ID IN(
          ?, ?, ?, ?, ?
      )

      size는 IN절에 올수있는 최대 인자 개수를 말한다. 만약 Member의 개수가 10개라면 위의 IN절이 2번 실행될것이다.

      그리고 만약 지연로딩이라면 지연로딩된 엔티티 최초 사용시점에 5건을 미리 로딩해두고, 6번째 엔티티 사용 시점에 다음 SQL을 추가로 실행한다.

      hibernate.default_batch_fetch_size 속성을 사용하면 애플리케이션 전체에 기본으로 @BatchSize를 적용할 수 있다.

      <property name="hibernate.default_batch_fetch_size" value="5" />

• @ControllerAdvice, @ExceptionHandler에 대해 설명하시오

  @ControllerAdvice

  컨트롤러를 보조하는 클래스에 사용하는 어노테이션.

  컨트롤러에서 쓰이는 공통기능들을 모듈화하여 전역으로 사용한다.

  @ExceptionHandler

  컨트롤러 메소드에 사용하는 어노테이션.

  어노테이션 인자로 전달된 예외를 처리한다.

  전달된 예외클래스와 확장된 클래스까지 처리한다.

  @ExceptionHandler 에러 처리 만들기

  Spring Web MVC - Annotated Controllers - Exceptions

  기본 사용 방법

  아래와 같이 클래스를 작성하였다고 가정하자.

  @Controller
  public class SimpleController {
  
      // ...@ExceptionHandler
      public ResponseEntity<String> handle(IOException ex) {
          // ...
      }
  }
  

  위와 같이 작성되면 해당 Controller의 메소드에서 발생한 IOException은 위에 @ExceptionHandler로 선언된 handle 메서드를 통해 에러가 처리된다.

  @ExceptionHandler({FileSystemException.class, RemoteException.class})
  public ResponseEntity<String> handle(IOException ex) {
      // ...
  }
  

  위와 같이 @ExceptionHandler에 대상 Exception 목록을 정의하여 처리 대상인 Exception 유형을 좀더 좁힐 수 있다.

  IOException 중 FileSystemException과 RemoteException 에 대해서만 해당 handle 메서드가 동작한다.

  @ExceptionHandler({FileSystemException.class, RemoteException.class})
  public ResponseEntity<String> handle(Exception ex) {
      // ...
  }
  

  위와 같이 대상 Exception을 @ExceptionHandler로 정의하고 일반적인 에러 유형인 Exception이나 또는 상위인 Throwable을 매개변수로 사용할 수도 있다.

  @ControllerAdvice와 같이 사용하기

  @Controller에 정의된 @ExceptionHandler는 해당 controller에서만 동작한다.

  모든 Controller에 대해 발생한 전역 에러에 대해 처리하는 @ExceptionHandler는 @ControllerAdvice와 같이 사용하면 된다.

  @Controller
  @ControllerAdvice
  public class GlobalExceptionController {
  
      // ...@ExceptionHandler
      public ResponseEntity<String> handle(IOException ex) {
          // ...
      }
  }
  

  위와 같이 @ControllerAdvice로 선언한 controller내에 정의된 @ExceptionHandler는 모든 controller를 대상으로 동작한다.

  controller 대상을 좁혀서 지정하고 싶은 경우 아래처럼 사용하면 된다.

  // @RestController를 사용한 모든 controller 대상@ControllerAdvice(annotations = RestController.class)
  public class ExampleAdvice1 {}
  
  // 해당 패키지 내 모든 controller 대상@ControllerAdvice("org.example.controllers")
  public class ExampleAdvice2 {}
  
  // 해당 클래스 하위로 구현된 controller 대상@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
  public class ExampleAdvice3 {}
  

Infra/운영 (김지훈)

• rest api method 에 대해서 설명하시오

  HTTP 메소드 정리

• http status code

  HTTP 응답코드