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

기술 문제

• JAVA (박효원)

  • Java8의 heap 메모리 구조를 설명해주세요 그리고 힙영역과 스택영역에 대해서 설명하시오

    • stack

      우리가 현재까지 작성하던 메소드 내에서 정의하는 기본 자료형(int, double, byte, long, boolean 등)에 해당되는 지역변수(매개 변수 및 블럭문 내 변수 포함)의 데이터의 값이 저장되는 공간이 Stack(스택) 영역이다.

    • heap

      참조형(Reference Type)의 데이터 타입을 갖는 객체(인스턴스), 배열 등은 Heap 영역에 데이터가 저장된다. 이때 변수(객체, 객체변수, 참조변수)는 Stack 영역의 공간에서 실제 데이터가 저장된 Heap 영역의 참조값(reference value, 해시코드 / 메모리에 저장된 주소를 연결해주는 값)을 new 연산자를 통해 리턴 받는다. 다시 말하면 실제 데이터를 갖고 있는 Heap 영역의 참조 값을 Stack 영역의 객체가 갖고 있다. 이렇게 리턴 받은 참조 값을 갖고 있는 객체를 통해서만 해당 인스턴스를 핸들 할 수 있다.

  • 자바8에서 소개된 람다식과 메소드 레퍼런스를 설명하라.

    • 람다란 식별자 없이 실행 가능한 함수이다.
    • 람다를 제공하기 위해서는 인터페이스 하나에 메소드 하나만 제공해야 한다. 이것이 함수형 인터페이스이다.
    • 람다식 장점
      • 코드를 간결하게 만들 수 있습니다.
      • 코드가 간결하고 식에 개발자의 의도가 명확히 드러나므로 가독성이 향상됩니다.
      • 함수를 만드는 과정없이 한번에 처리할 수 있기에 코딩하는 시간이 줄어듭니다.
      • 병렬프로그래밍이 용이합니다.
    • 람다식 단점
      • 람다를 사용하면서 만드는 무명함수는 재사용이 불가능합니다.
      • 디버깅이 다소 까다롭습니다.
      • 람다를 남발하면 코드가 지저분해질 수 있습니다. (비슷한 함수를 계속 중복생성 할 가능성이 높음)
      • 재귀로 만들경우에는 다소 부적합한면이 있습니다.
    • Stream이란 다양한 데이터를 표준화된 방법으로 다루기 위한 라이브러리이다.

  • checked-exception VS unchecked-exception 차이점을 설명해보세요.

    • Checked Exception
      • 반드시 예외를 처리 해야 한다.
      • 컴파일 시간에 확인 할 수 있다.
      • 예외 발생 시 롤백 불가능 하다.
      • 종류
        • IOException
        • SQLException
    • UnChecked Exception
      • 명시적인 처리를 강제하지 않는다.
      • 런타임에 확인 할 수 있다.
      • 예외 발생 시 롤백 가능하다.
      • 종류
        • NullPointerException
        • IllegalArgumentException
        • IndexOutOfBoundsException
        • SystemException
    • 예외 처리 방법
      • 예외 복구 : try, catch, finally 블록을 통해 예외가 발생할 경우 대처한다.
      • 예외 처리 회피 : throws 하여 예외 처리를 위임한다.
      • 예외 전환 : 예외가 발생하면 catch 블록안에서 내부 규정에 통용되는 예외로 변화하여 위임한다.

• SPRING (주종훈)

  • @Service, @Component의 차이는 무엇인가?

    • 스테레오 타입 : 스프링 컨테이너가 스프링 관리 컴포넌트로 식별하게 해주는 단순한 마커다.
    • @Component : 빈으로 간주되어 DI 컨테이너에서 사용할 수 있게 하는 기본 어노테이션이다.
    • @Service : Hibernate에게 Transaction을 가질수 있도록 알려준다.
    • @Repository : 검사 되지 않은 예외(DAO 메소드에서 발생)를 Spring DataAccessException으로 변환 할 수 있게 해준다.
    • @Controller : Dispatcher Sevlet에서 제공되며 여기서 @RequestMapping 어노테이션을 사용하여 클라이언트 요청을 특정 컨트롤러에 전달할 수 있게 해준다.

  • 스프링 MVC 웹 요청 처리과정을 설명하시오

    1. 클라이언트가 서버에 어떤 요청을 하면 DispatcherServlet이라는 클래스가 요청을 가로챈다.
    2. DispatcherServlet이 가로챈 요청을 HandlerMapping에게 보내 해당 요청을 처리할 수 있는 Controller를 찾는다.
    3. 모든 로직을 끝낸 서비스는 컨트롤러에 넘기고 컨트롤러는 Model객체에 결과물을 어떤 view로 보여줄 것인지 정보를 담아 디스패처서블릿에게 보낸다.
    4. DispatcherServlet은 응답할 View를 찾고 View는 응답로직을 처리한다.
    5. DispatcherServlet이 클라이언트에게 렌더링된 View를 응답한다.

  • @EnableWebMvc 는 어디에 필요한지 설명하시오

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE)
    @Documented
    @Import(DelegatingWebMvcConfiguration.class)
    public @interface EnableWebMvc {
    }
    

    @Import(DelegatingWebMvcConfiguration.class)해당 부분을 Import하게 되는데 해당 클레스와 그 속에서 상속하는 WebMvcConfigurationSupport를 보면 MVC에서 필요한 기본적인 세팅을 해주거나, 웹 관련 설정을 커스터마이징 할 수 있도록 기능을 제공하고 있습니다.

    따라서 DelegatingWebMvcConfiguration는 WebMvcConfigurer 를 implement한 빈들을 통해서 커스터마이징 할 수 있게 도아주는 클레스로 볼 수 있으며, DelegatingWebMvcConfiguration 에서 protected로 지원해는 함수의 설명을 보면 커스터마이징 할 수 있는 리스트를 확인할 수 있습니다

    WebMvcConfigurer 인터페이스를 implements 래도 되지만, 모든 메소드를 오버라이디이 해줘야 한다. 따라서, WebMvcConfigurer 보다는 WebMvcConfigurerAdapter 클래스를 extends 해서 필요한 메소드만 오버라이딩 해주는 편이 더 깔끔하다.  

• Infra/운영 (유정현)

  • heap dump를 튜닝하는 방법에 대해 설명해보세요.

  • 레디스 캐시를 어떻게 사용해야하나?

    레디스를 왜 사용하는가

    데이터 대부분을 디스크 또는 SSD에 저장하는 PostgreSQL, Cassandra, MongoDB 등 다른 데이터베이스와는 달리 모든 Redis 데이터는 서버의 주 메모리에 상주합니다. 작업을 위해 대부분 디스크까지 왕복해야 하는 전통적인 디스크 기반 데이터베이스와 대조적으로, Redis와 같은 인 메모리 데이터 스토어는 이와 같은 단점이 없습니다

    Cache의 대상이 되는 정보들

    1. 단순한, 또는 단순한 구조의 정보를 -> 정보의 단순성
    2. 반복적으로 동일하게 제공해야 하거나 -> 빈번한 동일요청의 반복
    3. 정보의 변경주기가 빈번하지 않고, 단위처리 시간이 오래걸리는 정보이고 -> 높은 단위처리비용
    4. 정보의 최신화가 반드시 실시간으로 이뤄지지 않아도 서비스 품질에 영향을 거의 주지 않는 정보

    더 많은 조건들이 있겠으나,저 조건들 중 2개이상 포함되는 성격의 서비스와 정보라면Cache를 적용하는 것을 적극적으로 고려해 보아도 큰 무리가 없을 것 같다.

    어떤 정보들을 Cache로 사용하나?

    • 포탈의 검색어
    • 쇼핑몰의 핫딜상품, 베스트셀러, 추천상품등
    • 상품의 카테고리와 카테고리별 등록상품 수
    • 방문자수, 조회수, 추천수
    • 1회성 인증정보 (SMS 본인인증정보, IP정보등)
    • 공지사항, Q&A

  • SSL 핸드쉐이킹 과정은?

    핸드쉐이크 단계

    1. 클라이언트가 서버에 접속한다.(Client Hello)

       서버에 전송되는 데이터

       • 클라이언트에서 생성한 랜덤 데이터

       • 클라이언트가 지원하는 암호화 방식들

       • 세션 아이디

    2. 서버가 클라이언트에 응답(전송)한다.(Server Hello)

       클라이언트에 전송되는 데이터

       • 서버에서 생성한 랜덤 데이터

       • 서버가 선택한 클라이언트의 암호화 방식

       • 인증서(서버의 공개키가 포함됨)

    3-1. 클라이언트는 클라이언트(웹브라우저)의 CA리스트를 확인하여 인증서가 CA에 의해서 발급된 것인지 확인한다. 웹브라우저에 내장된 CA의 공개키를 이용해서 인증서를 복호화하는 데 성공하면 이 인증서를 전송한 서버가 신뢰가능한 서버라는 것이 보증된다. 반면, 리스트에 없거나 복호화에 실패하면 사용자에게 경고 메시지를 출력한다.

    3-2. 클라이언트는 서버와 클라이언트에서 생성된 랜덤 데이터를 조합해서 Pre-Master Secret 키를 생성한다. (이 키는 뒤에서 살펴볼 '세션 단계'에서 데이터를 주고 받을 때 암호화하기 위해서 사용된다. 이 때 사용할 암호화 기법은 대칭키 방식이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다)

    3-3. 인증서에 포함된 공개키로 pre master secret 값을 암호화해서 서버로 전송한다.

    4-1. 서버는 자신의 비공개키로 안전하게 복호화한다. (이 시점에 C/S가 모두 Pre-Master Secret 값을 가지게 되었다.)

    4-2. C/S 모두 일련의 과정을 거쳐서 Pre-Master Secret 값을 Master Secret 값으로 만든다.

    4-3. master secret은 session key를 생성한다.

    5. C/S는 서로에게 핸드쉐이크 단계의 종료를 알린다.

출처

https://yonguri.tistory.com/82[대디장 일상 블로그]