[모의면접] Java

Java가 JVM 위에서 실행되는 과정을 설명해주세요.소스 코드(.java)를 javac 컴파일러가 바이트코드(.class)로 변환JVM이 Class Loader로 JVM 메모리 영역에 적재Execution Engine을 통해 네이티브 머신 코드로 번역하여 실행JDK / JRE / JVM 차이는?JVM(Java Virtual Machine): 바이트코드를 OS에 종속적인 기계어로 변환/실행하고 메모리를 관리하는 가상 머신JRE(Java Runtime Environment): JVM + 자바 핵심 라이브러리(Java API)를 포함하는 실행 전용 환경JDK(Java Development Kit): JRE + 개발 도구(javac, javap, jdb 등)를 포함하는 개발 키트 Bytecode란?특정 하드웨..

1. Process와 Thread의 차이를 설명해주세요.Process: OS로부터 독립된 자원을 할당받아 실행되는 작업 단위Thread: 프로세스 내에서 실행 흐름을 구성하는 최소 단위Thread끼리는 무엇을 공유하나요?Code, Data, Heap 영역 등 시스템 자원독립된 실행 흐름을 위해 Stack 영역과 레지스터/Program Counter는 각 스레드가 개별적으로 보유Multi Process와 Multi Thread의 장단점은?Multi-Process독립된 주소 공간을 가지기에 특정 프로세스의 장애가 전파되지 않아 안정적자원 점유가 크고 IPC 통신 비용과 Context Switching 비용이 크다.IPC: 프로세스 간 데이터를 주고받는 기법으로, Shared Memory와 Message Pa..

TCP와 UDP 차이전송 계층의 핵심 프로토콜로, 신뢰성과 속도 중 지향점에 따라 설계 방식이 다르다.TCP신뢰성 중시연결 지향형(3-way handshake)비교적 느린 속도스트림 단위데이터를 연속적인 바이트의 흐름으로 취급데이터의 끝을 프로토콜에서 구분하지 않는다.송신 측에서 send("Hello"), send("World")를 각각 호출해도 수신 측에서는 네트워크나 버퍼의 크기 등 상황에 따라 한 번에 "HelloWorld"를 전부 읽을 수도, "He"/"lloWorl"/"d"와 같이 나눠 읽을 수도 있다.HTTP(1,2), 이메일, 파일 전송 등 UDP속도 중시비연결형데이터 손실 여부를 확인하지 않아 비교적 낮은 신뢰성데이터그램 단위독립적이고 완결된 데이터 단위로 취급 => 패킷 유실 시 다른 데..

2차 배포 설계상황 가정우선순위최소 비용고가용성관측 가능성(Observability)서비스 규모항목v1v2v3타겟 유저KTB 교육생 (20대 중반-30대 초반)대학교 기숙사생, 1인 가구상태가 좋지만 불필요한 물품이 있는 한국 거주자SOM(목표 시장)30명100만 명500만 명MAU30명100만 명500만 명DAU30명25만 명125만 명Peak 동시 사용자20명12,50062,500체류 시간180초300초600초세션 평균 요청수271114.23세션 초당 요청수0.150.040.02Peak RPS35001,250트래픽 집중 시간평일 쉬는 시간(9:00-18:00 중 매시 50분부터 정각 사이) 점심시간(11:50-13:00)19-21시19-21시트래픽/자원 사용량 큰 기능이미지 업로드물품 등록 검증 시 ..

목표작은 비용과 운영 복잡도로 서비스를 빠르게 출시할 수 있는 환경 구축EC2를 몇 대 사용할 거야?어떤 애플리케이션을 컨테이너화할 거야?단순 구성을 선택함으로써 어떤 기술 부채를 감수했어?과연 서비스 규모에 맞는 적절한 아키텍처일까? 서비스 규모 v1v2v3타겟 유저KTB 교육생 (20대 중반-30대 초반)대학교 기숙사생, 1인 가구상태가 좋지만 불필요한 물품이 있는 한국 거주자SOM(목표 시장)30명100만 명500만 명MAU30명100만 명500만 명DAU30명25만 명125만 명Peak 동시 사용자20명12,50062,500체류 시간180초300초600초세션 평균 요청수271114.23세션 초당 요청수0.150.040.02Peak RPS35001,250트래픽 집중 시간평일 쉬는 시간(9:00-1..

게시판 커뮤니티 서비스에서 글 목록이나 댓글 목록을 조회하는 API는 어떻게 설계해야 할까? select * from posts;는 시간이 너무 오래 걸리고, 전체 게시글 데이터를 한 번에 전송해야 한다.데이터가 많을수록 지연, 병목, 장애 발생 확률이 높아지며, 오래 걸리는 작업이 중간에 문제가 생기면 복구 작업 등 복잡한 과정 속에서 문제는 커져만 갈 것이다. 인스타그램, 유튜브 등을 볼 때 인스타그램에 있는 모든 게시글을 전부 조회하지 않고, 설령 조회가 된다고 해도 다 안 본다.대충 미리보기만 보고 스크롤을 내린다고 해도 10개의 게시물을 보는 것조차 몇초는 걸릴 것이다.따라서 API도 당장 필요한 만큼의 데이터의 양을 나눠서 조회해야 할 것이다. 전체 데이터를 책 한 권이라고 하면, 당장 조회할..