** 📌PART 1.1 DispatcherServlet 동작 원리 & 메모리 흐름 **

📌 주제: “서블릿은 어떻게 작동하고 메모리를 어떻게 사용하는가?”

---

🟢 1단계: 서블릿은 뭐야? 중학생도 이해할 수 있게 설명

📦 서블릿(Servlet)은 자바로 만든 웹서버용 프로그램이야.

사용자가 버튼을 누르거나, 주소창에서 어떤 페이지를 요청했을 때

그걸 받아서 처리해 주는 “웹 서버 쪽의 뇌” 같은 역할이야.

---

⚙️ 2단계: 서블릿 동작 순서 정리 (init → service → doGet/doPost)

📌 전체 흐름 요약

[웹서버 시작 시]
👉 서블릿 객체가 한 번 만들어짐 → init() 실행됨

[사용자가 요청할 때마다]
👉 service() 호출됨 → 내부에서 doGet() 또는 doPost()로 분기됨

[웹서버 종료 시]
👉 destroy() 실행됨

---

🔍 1) init(): 딱 1번만 실행되는 준비 단계

• 서블릿이 최초로 실행될 때 메모리에 올라감
• init() 메서드는 “처음 준비” 단계로 한 번만 호출됨
• 이 시점에 서블릿 객체가 메모리에 올라가고 계속 살아있음

@Override
public void init() throws ServletException {
    System.out.println("📌 최초 1회 서블릿 초기화");
}

🧠 면접 포인트:

서블릿은 싱글 인스턴스(single instance)이며, init은 딱 1번만 호출됨 (기억해두세요!)

---

🔍 2) service(): 사용자가 요청할 때마다 실행됨

• 사용자가 페이지를 요청하면 가장 먼저 실행되는 메서드
• 내부적으로 요청 방식(GET/POST) 에 따라 doGet() 또는 doPost() 호출

@Override
protected void service(HttpServletRequest req, HttpServletResponse res) {
    System.out.println("📌 모든 요청 진입점 (GET/POST 상관없이 들어옴)");
}

---

🔍 3) doGet() / doPost(): 실제 업무 수행

• 사용자가 버튼 클릭 또는 주소창 입력 → GET 방식이면 doGet()
• 회원가입처럼 데이터를 제출하는 POST 방식이면 doPost()

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse res) {
    System.out.println("✅ GET 요청 처리");
}

---

🔍 4) destroy(): 종료 시 자원 정리

• 서버가 종료되거나 서블릿이 더 이상 필요 없을 때 실행
• DB 커넥션이나 파일 등 정리할 때 사용

@Override
public void destroy() {
    System.out.println("🧹 메모리 정리 (서버 종료)");
}

---

🧠 3단계: 메모리 구조 — 서블릿은 메모리에 이렇게 올라간다!

🧩 메모리 흐름 요약

항목	내용
클래스 영역	서블릿 클래스 자체 (딱 1개만 메모리에 올라감)
힙 영역	요청 처리 중 사용하는 변수들
스택 영역	각 요청마다 생성되는 로컬 변수
쓰레드	사용자가 요청할 때마다 서버가 새로운 쓰레드로 처리

📌 도식으로 보기

[서버 기동 시]
📁 BoardController.class → 메모리에 1번 로딩
   └ init() 실행

[사용자 1 요청]
🧵 Thread A → service() → doGet() 실행

[사용자 2 요청]
🧵 Thread B → service() → doPost() 실행

---

🧠 4단계: 쓰레드 풀 + 동시 사용자 처리 방식

💡 서블릿은 “멀티 쓰레드”로 동작한다는 걸 기억하세요!

• 하나의 서블릿 객체가 여러 사용자의 요청을 처리해야 함
• 요청마다 새로운 쓰레드(Thread)가 만들어져서 동시에 처리됨
• 자바 서블릿 컨테이너(Tomcat)는 쓰레드 풀(Thread Pool) 구조 사용
  • 미리 쓰레드를 여러 개 만들어 놓고 요청이 올 때 꺼내 씀

🧠 면접 포인트:

“서블릿은 쓰레드 세이프(Thread-safe)한가요?”

→ 아니요! 공유 변수(static, 인스턴스 변수) 사용할 땐 동기화 필요

---

✅ 5단계 요약: 전체 흐름 요약 + 면접 질문 대비

구분	설명	면접 포인트
init()	최초 1회 실행, 메모리에 객체 생성	언제 호출되나요? GC 대상인가요? (X)
service()	요청마다 호출, GET/POST 판단	왜 직접 오버라이딩 하나요?
doGet()	GET 요청 처리	사용자의 URL 직접 입력 요청
doPost()	POST 요청 처리	form 태그 submit 처리
Thread	요청마다 쓰레드가 다름	동시성 이슈 발생 가능성

---

🎓 실무·면접 예제 질문

1. 서블릿은 왜 싱글 인스턴스인가요?
2. init()은 언제 호출되고, destroy()는 언제 호출되나요?
3. 사용자 1000명이 동시에 요청하면 메모리에서 어떤 일이 벌어지나요?
4. 서블릿에서 인스턴스 변수(static 제외)를 쓰면 안 되는 이유는?
5. 쓰레드 풀의 크기가 부족할 때 어떤 문제가 발생하나요?

✅ PART 1.2 요청 라우팅 (URL → 메서드 매핑)

---

🟢 1단계. 요청 라우팅이 뭐야? (기초 개념)

📦 정의

사용자가 웹 브라우저에서 어떤 주소(URL) 를 입력하거나 버튼을 누르면,

그 요청을 처리하는 Java 서블릿의 메서드로 연결해 주는 것을 “요청 라우팅(Routing)”이라고 해.

---

예시

[사용자 요청]
http://localhost:8080/myapp/board/list

[어떤 코드가 실행돼야 할까?]
→ BoardController.java의 list() 메서드가 실행!

👉 이걸 URL → 메서드 매핑이라고 해!

---

🟢 2단계. URL 패턴 매핑 종류 (/*, /controller/*)와 메모리 차이

1. /

• 모든 요청을 처리할 수 있음 (가장 범위가 넓음)
• 예: @WebServlet("/")

📛 주의: 정적 리소스까지 다 가로채서 JSP나 이미지가 동작 안 할 수 있음

---

2. /*

• 루트 경로 포함, 전체 요청을 처리함
• JSP 포함 모든 경로를 가로채기 때문에 예외 상황 주의 필요

---

3. /controller/*

• /controller/로 시작하는 URL만 처리
• 실무에서 가장 자주 쓰임
• 예:

@WebServlet("/controller/*")

👉 이런 경로로 들어오면 처리됨: /controller/write, /controller/list

---

✅ 메모리적 차이

패턴	메모리 영향	설명
/	무거움	모든 요청을 가로채 GC 부하↑
/*	중간	JSP, 이미지까지 가로채 주의
/controller/*	효율적	필요한 요청만 처리하므로 메모리 효율↑

🧠 면접 포인트

• 왜 실무에서는 /controller/* 같은 좁은 범위 매핑을 선호하나요?

  👉 메모리 낭비 없고, 정적 리소스 가로채지 않음

---

🧠 3단계. @WebServlet vs web.xml 매핑 차이

항목	@WebServlet (애노테이션 방식)	web.xml (설정 파일 방식)
작성 위치	Java 코드 위에 직접 작성	XML 설정 파일에서 설정
가독성	좋음	분리되어 있음
유지보수	클래스 안에서 보기가 쉬움	큰 프로젝트에서 설정만 따로 관리 가능
실무 활용	소규모 프로젝트에 적합	대규모 시스템에서 선호

---

✅ 예제: @WebServlet

@WebServlet("/board/*")
public class BoardController extends HttpServlet {
    ...
}

---

✅ 예제: web.xml

<servlet>
  <servlet-name>board</servlet-name>
  <servlet-class>controller.BoardController</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>board</servlet-name>
  <url-pattern>/board/*</url-pattern>
</servlet-mapping>

---

🧠 고급 면접 개념

• 웹 컨테이너는 서버 시작 시 web.xml 또는 @WebServlet을 읽고

  → 요청 URL에 어떤 서블릿을 연결할지 “라우팅 테이블”에 등록함

  → 이 과정이 빠르게 끝나야 성능이 좋아짐 (Tomcat 초기화 시간과 관련)

---

🧠 4단계. Annotation 기반 라우팅 프레임워크 설계 (@RequestMapping 직접 구현)

💬 쉽게 말하면:

스프링처럼 URL마다 메서드를 자동으로 연결하고 싶을 때,

@RequestMapping("list") 이런 식으로 메서드에 URL을 붙이는 방식이 필요해.

---

✅ 우리가 직접 만들 경우

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RequestMapping {
    String value();
}

---

예시 사용

@RequestMapping("list")
public String list(HttpServletRequest req, HttpServletResponse res) {
    ...
}

---

🎯 핵심 설계 개념

• Reflection (리플렉션) 으로 모든 메서드를 뒤져서 @RequestMapping("list")가 붙은 메서드를 찾아낸다
• URL 요청이 /board/list로 오면 → list() 메서드가 실행되도록 연결

---

🧠 구현 시 주의점

항목	설명
메모리	Reflection은 느리므로 캐시 전략 필요
속도	메서드 검색을 반복하지 않도록 최초 실행 시 라우팅 Map으로 저장
실무	Spring에서는 HandlerMapping, DispatcherServlet이 이걸 관리함

---

✅ 최종 요약: 이 파트에서 외워야 할 것

항목	내용
/* vs /controller/*	좁은 범위 매핑이 성능, 메모리에 좋다
@WebServlet vs web.xml	프로젝트 규모에 따라 선택
Annotation 라우팅	Reflection으로 메서드 연결, 캐싱 전략 필요

---

💡 면접 예상 질문

1. 서블릿 매핑을 /*로 했을 때 발생할 수 있는 문제는?
2. @WebServlet과 web.xml 방식의 장단점은?
3. @RequestMapping("list")을 직접 만들 때 어떤 문제가 생길 수 있나요?
4. URL → 메서드 매핑을 효율적으로 만들기 위한 메모리 캐싱 전략은?

🟢PART 1.3 Request, Response, Session 객체 생명주기 완전 정복

---

🟢 1단계. “스코프(scope)”가 뭐야?

💬 스코프(Scope)는 “데이터가 얼마 동안 살아 있냐?” 를 말해.

쉽게 말하면 변수나 데이터가 언제 생성되고, 언제 사라지는지를 구분하는 거야.

---

🧩 2단계. JSP/Servlet에서 쓰는 3가지 주요 스코프

이름	살아 있는 시간	저장 위치	예시
RequestScope	요청(request) 1번 동안	HttpServletRequest	검색 결과, 글쓰기 처리 결과
SessionScope	브라우저가 켜져 있는 동안 (로그인 세션)	HttpSession	로그인 정보
ApplicationScope	서버가 켜져 있는 동안	ServletContext	전체 사이트 공통 설정

---

🔍 각각 스코프의 작동 방식 자세히 보기

---

✅ 1. RequestScope (요청 하나만 유지)

• 요청을 보냈을 때만 존재, 응답하면 사라짐
• 대표 객체: HttpServletRequest
• 데이터 저장:

request.setAttribute("msg", "처리 완료!");

• JSP에서 출력:

${msg}

📦 예시

• 글쓰기 성공 메시지 보여줄 때
• 검색 결과 1회 출력할 때

🧠 면접 포인트:

RequestScope는 다른 JSP로 forward 시에만 데이터가 넘어감.

Redirect는 새로운 요청이라서 데이터가 사라짐!

---

✅ 2. SessionScope (로그인 세션 유지)

• 브라우저가 열려 있는 동안 유지
• 대표 객체: HttpSession
• 저장 예시:

HttpSession session = request.getSession();
session.setAttribute("loginId", "hong");

📦 예시

• 로그인한 사용자 아이디 저장
• 장바구니 저장

⏳ 생명주기

• 브라우저를 닫거나 로그아웃하거나 session.invalidate() 하면 삭제됨

---

✅ 3. ApplicationScope (서버 전체에서 공유)

• 서버가 꺼질 때까지 살아있음 (아주 오래)
• 대표 객체: ServletContext
• 저장 예시:

ServletContext app = request.getServletContext();
app.setAttribute("visitorCount", 1234);

📦 예시

• 접속자 수
• 글로벌 설정 정보 (글자 인코딩, 업로드 경로 등)

---

🧠 3단계. 메모리 관점에서 보는 각 스코프

스코프	메모리 영향	설명
Request	메모리 부담 적음	요청마다 GC 대상, 일회성
Session	중간 정도	사용자 수가 많아지면 세션 메모리↑
Application	메모리 부담 큼	잘못 쓰면 전체 서버 리소스를 먹음

---

🎯 4단계. 스코프 충돌 시 전략 (면접 포인트)

💬 문제 상황:

동일한 이름의 변수 "msg"가

• Request에 있음 → "요청 성공!"
• Session에도 있음 → "로그인 됨"
• Application에도 있음 → "전체 알림"

😱 JSP에서 ${msg} 라고 하면 어떤 값이 나올까?

👉 EL(Expression Language)는 범위 우선순위가 있음

우선순위 (높음 → 낮음)

---

1. PageScope (JSP 내부 변수)

---

1. RequestScope

---

1. SessionScope

---

1. ApplicationScope

---

---

✅ 충돌 시 처리 전략

전략	설명
범위를 명시하자	${sessionScope.msg} 로 정확히 지정
변수명 다르게	loginMsg, alertMsg처럼 역할마다 다르게
객체별로 관리	DTO/VO 클래스 내부 필드로 구분해서 관리

---

💡 면접 예상 질문 리스트

1. request.setAttribute()로 저장한 데이터는 언제 사라지나요?
2. request와 session에 같은 이름으로 데이터를 저장하면 어떤 게 먼저 보일까요?
3. ServletContext에 데이터를 저장하면 어떤 위험이 있을까요?
4. 로그인 상태는 어떤 스코프에 저장하는 것이 좋은가요?
5. forward()와 redirect()의 데이터 전달 차이점은?

---

✅ 마무리 요약 표

스코프	객체	유지 시간	사용 용도
Request	HttpServletRequest	요청 1번	검색 결과, 오류 메시지
Session	HttpSession	로그인/브라우저 세션	로그인 정보, 장바구니
Application	ServletContext	서버 살아있는 동안	사이트 설정, 공통 데이터

---

✍️ 외워야 할 실무 포인트

• 🔸 RequestScope는 forward() 가능, Redirect 시 사라짐
• 🔸 SessionScope는 사용자가 많을수록 메모리 주의!
• 🔸 ApplicationScope는 모든 사용자에게 공유됨 → 쓰레드 동기화 고려