면접대비
- 자바 백엔드
- 공부하면 좋은 리스트
- 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
- 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
- Major GC
- 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
- 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 - 장애처리