백엔드 기술 면접 대비(HTTP, JAVA, Spring, JPA 등)

면접대비

• 자바 백엔드
  • 공부하면 좋은 리스트
    • HTTP, JAVA, Spring, JPA, NoSQL, DB, 인증, MSA, Kotlin 등
      • HTTP
        • HTTP에 대해 아는 대로 설명
        • HTTP의 특징
        • Stateless란
        • HTTP 요청 메서드들
          • GET vs POST
            • GET은 쿼리스트링으로 조회되기 때문에 보안상으로 좋지 않다
            • POST는 데이터가 헤더가 아니라 바디에 있지만 GET보다 보안에 강하진 않다. 피들러?같은걸 사용하면 바디를 조작할 수 있다.
            • 보안 관련된 것을 얘기할 때는 POST는 바디에 담겨있어서 보안에 강해보이지만, 모두 조회가 가능하기 때문에 HTTPS를 통해서 암호화로 서버에 던지는 것이 필요하다.
          • PUT vs PATCH
        • 상태코드들(204, 401, 403)
        • 버전 별로 구분
          • 1.0
            • TCP기반
          • 1.1
            • 힙 어라이브 기능이 추가되어서 기존 연결에 대해서 handshake하는 과정을 생략할 수 있도록 추가
          • 2.0
            • TCP기반
            • 새로운 요청마다 handshake하는 것이 아닌, 하나의 커넥션을 맺고 병렬적으로 처리할 수 있도록 하는 기능 추가
          • 3.0
            • UDP기반
            • quic 퀵 프로토콜이 만들어져서 빠르지만 신뢰성도 있도록 구성
        • HTTP(80) vs HTTPS(443)
          • 보안계층을 이용해서 암호화
          • HTTPS는 SSL 암호화 기법을 이용해서 Secure Socket Layer에서 암호화하며, 양방향 암호화 알고리즘(공개키, 개인키)를 통해 구성
          • 공개키를 통해 암호화해서 클라이언트가 서버로 보내고, 서버에서 개인키로 복호화해서 사용
          • 보안상 완전하게 안전하다곤 못함(키값을 해킹한다면), 그래도 키 값이 탈취되기 전까진 안전하다
      • JAVA
        • JVM 메모리 구조
          • Code / Data / Stack / Heap
          • Data - method area 공간 클래스, 전역변수, static
          • PC Register - 쓰레드 관련 정보
          • Native Method Stack - 언어들 관련된 공간
        • 객체 지향
        • Garbage Collector
          • Heap에서 사용하는 것
          • C/C++ 처럼 동적 할당을 한 뒤 해제할 때 직접 해제해주는 것이 아닌, Java에서 오래 사용하지 않는 것들을 모아서 나중에 일괄 처리 하는 방식(메모리 누수 방지)
          • GC 동작 방식
            • young 영역 : 객체들이 생긴지 얼마 안됨
              • 에덴 영역 : 객체로 새로 태어난 곳
              • 서바이버 0 영역 : 에덴에서 살아남은 영역
              • 서바이버 1 영역 : 0에서 살아남는 영역
            • old 영역 : 생긴지 조금 오래된 영역(서바이버 1에서 옮김)
            • 커머넌트 영역 : 영구..?
          • Minor GC
            • young 영역에서 일어나는 것
          • Major GC
            • old 영역에서 일어나는 것
          • Stop the world
            • GC가 일어나는 메인 쓰레드가 작동할 때 나머지 쓰레드가 모두 멈추는 현상이 발생
            • GC가 끝난 다음에 나머지 쓰레드들을 실행하는 것
          • GC 종류
            • 지금 사용하는 자바에서 사용하는 GC가 무엇인지 물어볼 수 있다
            • G1GC
              • JAVA 9 보다 G1GC를 사용한다
              • G1GC를 default로 사용하고 있다는 걸 알아야 한다
              • 다른 GC들을 사용하지 않는 공간을 추적하며 판단하고 해소하는데, G1GC는 굳이 하나하나 찾아다니는 것이 아니라 특정 region에서 가득 채웠다면 region 자체를 회수하는 방식으로 동작(그래서 성능이 더 좋다)
        • 사용하는 버전, JAVA XX버전의 특징
        • 인터페이스 vs 추상클래스
          • 인터페이스는 상수, 추상메서드로 구성되어있으며, 반드시 상속 객체에서 재정의를 필요로 한다.
          • 추상클래스는 공통적으로 사용하는 것이 들어있으나 구현하는 쪽에서 각각 다르게 재정의하도록 하자
          • 상속을 하는 목적
            • 코드의 재 사용성
              • 자손마다 재 사용해야하는 것들을 다시 작성하지 않아도 된다
              • 자바에서 다중 상속이 되는지?
                • 인터페이스는 가능한데, 일반 클래스는 되지 않는다
                • 왜 일반 클래스는 다중 상속을 막아놓았을까?
                  • 다이아몬드 문제
                    • A, B,C, D(B,C상속)
                    • 위에 있는 부모 클래스를 바라보게 되는데, 메소드가 같은 이름이 있다면 어떤 메소드를 가져와야할지 모르게 되는데, 다이아몬드 문제에서 발생하게 된다
        • Object class
          • 모든 클래스가 상속받은 최상단 클래스
        • static 키워드 장단점
          • 장점
            • Code, Data, Stack, Heap
            • 메모리 구조를 설명하면 좋다(jvm과 함께)
            • 클래스 정보, 전역-스태틱 변수를 미리 저장하기 때문에 언제든 접근 가능한 변수를 만들 수 있다
            • new를 이용해서 객체를 만들지 않기 때문에 → 정적 팩토리 메서드?, 언제든 함수호출 가능
            • new는 heap영역인데, static은 Data 영역이라서, GC가 관리하지 않기 때문에 오버헤드도 적다
          • 단점
            • 프로세스가 종료될 때까지 Data 메모리 영역에 남아있어서 메모리를 계속 잡아먹는다
            • 객체 지향적이지 않다(캡슐화 위반)
              • 언제든 접근이 가능하기 때문에 캡슐화 위반
              • 쓰레드 세이프하지 않다(race condition)
        • final 키워드
          • final 변수
            • 상수화(불변)
          • final class
            • 클래스를 상속을 할 수 없게 만든다
            • (이 클래스를 다음 클래스가 상속 받을 수 없다)
          • final method
            • 상속을 받았을 때 재정의를 하지 못하도록 만든다
            • (더 이상 상속되지 않도록 하는)
        • ==, equals 차이
          • 자바 최신버전부터는 해결됐을…수도 있다
          • == 같은 메모리 포인터인지까지 확인
          • equals 같은 값인지만 확인
          • 코틀린에서는 차이가 없다
        • 접근 제어자 종류와 특성
          • default
            • 같은 패키지 내에서 접근이 가능
          • private
            • 해당 클래스에서만 호출이 가능
          • protected
            • 같은 패키지, 상속받은 클래스에서 호출이 가능
          • public
            • 어느 곳에서든 호출이 가능
        • Throw vs Throws
          • throws는 그 메서드에서 exception이 발생하면 이 예외를 처리하는 곳으로 넘기는 것
        • Error vs Exception
          • 시스템적으로 발생하는 것을 Error, 어플리케이션 상에서 잡아낼 수 있는 에러를 Exception이라고 한다
        • Checked exception
          • 컴파일 시 확인할 수 있는 예외
          • ide가 try catch 하라고 추천해주는 것
          • io exception은 발생해도 roll back이 되지 않는다
        • Unchecked exception
          • 런타임 exception을 상속받는 애들
          • 런타임 시 확인할 수 있는 예외
          • 처리/비처리를 선택을 할 수 있다
        • 리플렉션
          • 어떤 객체를 통해서 클래스 정보를 알아내는 것
        • String vs StringBuffer vs StringBuilder
          • String
            • String 클래스는 불변한가요? 그렇다(이미터블?)
            • 문자열 연산 시, 새로운 문자열을 만들 시 새로운 공간을 할당받고 넣기 때문에 상당히 비 효율적이다
          • StringBuffer
            • 연산 시 객체를 생성하지 않고 원래 있던 객체를 변경해서 사용
            • 쓰레드 세이프하게 만들어져 멀티 쓰레드 환경에서 안전하게 사용 가능(그러나 느리다)
          • StringBuilder
            • 연산 시 객체를 생성하지 않고 원래 있던 객체를 변경해서 사용
            • 동시성 문제 발생 가능
        • 동시성 처리 방법
          • atomic..? volitile..? lock 클래스가 따로 있다
          • concurrentHashMap
          • 종류
            • @synchronized
              • 멀티 쓰레드 환경에서 특정 메서드가 들어가면 다른 쓰레드가 접근할 수 없도록 blocking된다(동시성 보장)
            • volitile
              • 메인 쓰레드에서 값을 불러올 때 캐쉬 메모리에 있는 값을 가져올 때 두 개의 데이터가 빗나가는 현상이 발생하면 캐쉬 메모리를 부른 것이 아닌 메인 메모리에서 불러오도록 하게 하는 키워드
              • 완벽하진 않다, 모든 쓰레드들이 읽고 쓰기가 가능해지면 동시성 문제가 발생한다
              • 하나의 쓰레드만 쓰기가 가능하고, 다른 쓰레드들은 읽기만 가능하다면 이것으로 해결이 가능하다
            • atomic
              • 트렌잭션의 성질 중 하나로 원자성을 의미
              • 한 번에 접근하더라도 한 번에 하나만 처리하기 때문에 동시성 처리를 할 수 있다
            • lock 객체
              • new Lock을 통해 lock을 만들어 접근하지 못하도록 막는다
            • concurrentHashMap
              • Thread safe하면서 해쉬맵의 성능도 보장하도록 만들어져있다
      • Spring
        • Spring framework란
          • 자바, 코틀린 언어로 웹 개발을 편리하게 지원해주는 경량화 어플리케이션 프레임워크이다
          • 스프링 이전 EJB가 너무 무거워서 웹 개발에 필요한 애들만 모아서 경량화 시켜서 경량화 프레임워크이다
          • 단점 : 생각보다 경량화되어있지 않다
            • 노드가 훨씬 가볍다
            • 기능이 많고 무겁다
        • IoC
          • 개발자가 아닌 스프링에게 의존성을 부여하는 제어권을 스프링에게 넘겨주는 것
        • DI
          • 기존에는 하나하나 생성했다면, @Bean을 통해서 Component scan을 통해서 의존성을 주입시켜는 형태
          • Spring DI 하는 방법
            • 생성자 주입, 필드 주입, 메서드 주입
            • 생성자 주입(추천)
              • 필드 주입은 컴파일 시점에 알 수가 없다
              • 생성자 주입은 바로 에러 확인이 가능하고
              • final 키워드를 이용해 불변성 적용 가능
              • 순환 참조 에러를 생성자 주입을 통해 방지 가능
        • AOP(Aspect Oriented Programming)
          • 관점 지향 프로그래밍
          • 비즈니스 로직을 제외해서 나머지 공통적으로 쓰는 것들을 모듈화해서 사용하는 것
          • 관점 지향은 어떤 로직을 기준으로핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 모듈화 하겠다는 것
        • 싱글톤
          • 하나의 클래스에 하나의 인스턴스만 존재하는 구조
          • 왜 스프링은 bean으로 싱글톤을 택 했을까
            • 스프링은 톰캣을 사용한다
            • 톰캣은 멀티 쓰레드 기능이기 때문
            • 멀티 쓰레드 환경에서 싱글톤이 아니면, 사용자마다 너무 많은 객체를 만들게 되서 메모리가 부족해진다
            • 만약 싱글톤 객체로 생성되어 있지 않다면 성능 저하가 발생한다
          • 싱글톤의 단점
            • static 문제처럼 캡슐화를 위반하게 되어 객체지향적이지 않다
            • 동시성 문제 발생(필히 발생)
              • 동시성 문제를 해결할 수 있느냐?로 이어진다
        • Spring MVC (찾아봐야한다, 확실x..)
          • WAS → 필터 → 디스패처 서블릿 → 인터셉터 → 핸들러 매핑 → 컨트롤러 → 서비스 → 리포지토리 → 값 반환(모델) → 뷰 리졸버
        • Filter vs Interceptor
          • 처리 시점이 다르다
            • filter를 거쳐서 디스패처 서블릿
            • interceptor를 거쳐서 그 다음으로
          • 어떤 경우에 사용하는지, 근거는?
            • 디스패처 서블릿을 통과하면 spring bean을 이용할 수 있다
            • filter는 spring bean을 사용할 수 없다
            • 그래서 bean을 이용해야 한다면 interceptor를 사용해야 한다
        • Spring boot란
          • 장점
            • 예전 spring에서는 web.xml에서 복잡한 설정을 해야하는데, 그것이 어렵다
            • 복잡한 설정을 없애버리고, 의존성 설정을 쉽게 할 수 있도록 만들어 준 것
          • auto configuration 동작 방식
            • SpringFactoryes 파일을 읽어와서 처리한다..?
    • JPA
      • N+1 problem
        • 1:N, N:N 관계에서 쿼리 하나를 날리면 쿼리 1+N개가 호출되는 현상
        • fetch join을 이용하면 관련된 정보를 한 번에 가져오게 된다
        • batch size를 이용해서 in 절로 가져올 수 있다
      • isolation 속성(격리 수준)
        • transaction끼리 부딪치면 생기는 문제들이 있다
          • dirty read
            • 롤백된 정보를 가지고 있는 것
            • commit된 데이터만 읽을 수 있다는 설정이 필요
        • level별로 암기
          • Read Uncommited(level0): 커밋되지 않은 데이터도 읽을 수 있다Dirty Read, Dirty Write가 가능하다
          • Read Commited(level1): 커밋된 데이터만 불러온다(반복해서 같은 데이터 호출 X) select 문장이 수행되는 동안 해당 데이터를 shared lock이 걸린다, dirty read 방지
          • Repeatable read(level2): 트랜잭션 동안 한 번 조회한 데이터를 계속 조회해도 같은 데이터가 나오지만, 만약 다른 트랜잭션에서 데이터를 추가한 경우 기존 트랜잭션을 반복 조회 시, 결과 집합이 새로 추가된 데이터를 포함한 결과를 가져온다
          • Serializable(level3): 모든 트랜잭션이 순서대로 수행된다Dirty Read, Noorepeatable Read 방지, Phantom Read 방지 X
      • propagation 속성(전파 수준)
        • 부모 트랜적션이 있다면 다 실행하자? 찾아봐야할듯
      • JPA Entity 객체 생명주기
        • managed
          • 영속성 컨텍스트에 저장된 상태
          • Entity가 영속성 컨텍스트에 의해 관리되는 상태
          • 영속 상태가 된다고 바로 DB에 쿼리가 날라가지 않는다
          • commit 시 영속성 컨텍스트에 있는 정보들이 DB로 쿼리가 날라간다
        • detached
          • 준영속
          • 영속성 컨텍스트에 저장되었다가 분리된 상태
          • 영속성 컨텍스트에서 지운 상태(DB에는 존재할 수도 있다)
        • New
          • 비영속
          • 영속성 컨텍스트와 전혀 관계가 없는 상태
        • Removed
          • 실제 DB 삭제를 요청한 상태
      • Persistence Context
        • DB까지 접근하지 않고 같은 쿼리에 대해서 값을 저장하는 컨텍스트
      • 낙관적(optimistic) 락 vs 비관적(pessimistic) 락
      • RDBMS vs NoSQL
    • 그 외
      • 쿠키 vs 세션
        • HTTP는 stateless해서 사용자 상태를 저장하기 위해서 쿠키는 사용자 환경에, 세션은 서버에 사용자 상태를 저장하는 방식
        • 세션 데이터를 서버에서 관리하기 때문에 많아지면 많아질수록 서버 데이터에 문제가 생길 수 있다
      • jwt vs OAuth2
        • jwt는 토큰이여서 여러가지 인증정보를 담아둠으로 써 굳이 db조회를 하지 않더라도 알 수 있어 탈취된 경우 보안 상 위험하여 주기적으로 refresh를 통해 관리
        • OAuth2는 인증된 사용자 정보를 통해 관리를 하는데, 사용자의 access token같은 걸 이용해서 인증된 서버 요청을 하면, 유효한 access token일 경우 인증된 사용자 정보를 준다
      • 대용량 트래픽 처리 방법
        • 성능 개선과 엮여있다
        • 데이터 많은 요청을 빠르게 처리하여 대용량 트래픽을 처리하는 것
        • 네트워크 트래픽 조절
        • DB를 계속 조회하지 않고 캐시를 두어 캐시에서 빠르게 데이터 조회
        • 데이터베이스 인덱스 확인
        • 데이터베이스 샤딩
        • MSA - 장애처리