📌 PART 3.1 JSP → 서블릿 변환 과정 + 메모리 구조 분석

🟢 1단계. JSP는 어떻게 작동할까? (기초 설명)

📄 JSP는 그냥 HTML 파일처럼 보이지만, 사실은

백엔드에서 동적으로 HTML을 만드는 “자바 코드”로 변환돼.

✅ JSP 실행 순서 요약

[JSP 파일 요청]
 → [서버가 JSP를 "서블릿"으로 바꿈 (.java 파일 생성)]
 → [그 .java를 컴파일해서 .class로 만듦]
 → [그 .class 파일을 실행해서 HTML을 출력]

🔍 예시

JSP 코드:

<% out.println("안녕하세요!"); %>

→ 내부에서는 다음과 같이 서블릿 코드로 변환됨:

public void _jspService(HttpServletRequest request, HttpServletResponse response) {
    response.getWriter().write("안녕하세요!");
}

🧠 2단계. JSP → 서블릿 변환 타이밍 (2가지 방식)

방식	설명	실무 포인트
최초 요청 시	JSP를 처음 요청할 때 → 변환됨	기본 설정
서버 배포 시 (precompile)	WAR 배포할 때 미리 서블릿으로 변환	대규모 서비스에서 추천

💡 왜 precompile이 좋을까?

첫 사용자가 느리지 않게 하기 위해, 미리 컴파일해두는 전략

→ 요청 폭주 초기 지연을 방지

🧬 3단계. _jspService() 구조 분석

JSP가 서블릿으로 바뀌면 내부에 _jspService() 메서드가 자동 생성됨.

✅ 예시 구조

public final class test_jsp extends HttpJspBase {
    public void _jspService(HttpServletRequest request, HttpServletResponse response) {
        response.setContentType("text/html;charset=UTF-8");
        JspWriter out = response.getWriter();

        out.write("<html><body>");
        out.write("안녕하세요!");
        out.write("</body></html>");
    }
}

💡 특징

항목	설명
메서드 이름	`_jspService()` (JSP 전용 메서드)
호출 방식	사용자가 JSP를 요청할 때마다 자동 호출
사용 객체	`request`, `response`, `out`, `session` 등 JSP 내장 객체 전부 사용 가능
재정의 불가	이 메서드는 오버라이드할 수 없음 (JSP 컨테이너에서 자동 생성됨)

💾 4단계. JSP가 메모리에 어떻게 보관될까?

✅ 실행 파일 생성 위치

파일	위치 (Tomcat 기준)
`.java`	`/work/Catalina/localhost/프로젝트명/org/apache/jsp/`
`.class`	같은 경로, 컴파일된 파일 (.class)

→ 이 파일은 Tomcat이 JSP를 변환해서 자동으로 생성함

✅ 메모리 구조

구조	설명
클래스 영역	`_jspService()` 메서드를 가진 클래스가 올라감
힙 영역	`request`, `session`, `out` 객체가 생성됨
스택 영역	각 요청별로 지역변수 저장 (JSP 실행 시)

📌 GC 관점

_jspService()는 요청이 끝나면 참조가 사라짐 → GC 대상
단, JSP 자체 클래스는 서버가 내려갈 때까지 유지됨
이 클래스가 너무 많으면 PermGen 또는 Metaspace 영역 사용량 증가

→ 메모리 누수 위험

✅ 요약: JSP 실행 흐름 한눈에 보기

[JSP 요청]
→ [JSP → 서블릿으로 변환 (.java)]
→ [.java → .class 컴파일]
→ [클래스 메모리에 적재]
→ [_jspService() 실행 → HTML 출력]
→ [응답 종료 → 일부 객체는 GC 대상]

🎯 실무 성능 고려사항

항목	설명
JSP precompile 사용	대량 트래픽 대비 가능
너무 많은 JSP 파일	클래스 파일이 많아져 PermGen/Metaspace 누수 가능
`out.write()` 반복	BufferedWriter 기반이므로 flush 시기 중요
HTML이 복잡할수록	`_jspService()`의 코드가 길어지고, 성능 저하 우려 있음

💡 면접 예상 질문

JSP는 어떻게 서블릿으로 바뀌나요?
JSP가 서블릿으로 변환되는 타이밍은 언제인가요?
JSP 내의 <% %> 코드는 어떤 자바 메서드로 들어가나요?
JSP 파일이 많을 때 서버 성능에 어떤 영향이 있나요?
JSP를 precompile하면 어떤 장점이 있나요?

✅ 마무리 요약표

항목	설명
JSP 변환 시점	최초 요청 시 or 배포 시 (precompile)
핵심 메서드	`_jspService()` (JSP가 서블릿이 되면 자동 생성)
메모리 위치	클래스 영역(코드), 힙 영역(객체), 스택 영역(지역 변수)
GC 대상	요청 종료 후, request/response 객체 등은 GC 수거됨

✅ PART 3.2 태그 라이브러리(JSTL)의 메모리 특징

🟢 1단계. 태그 라이브러리가 뭐야?

💬 태그 라이브러리는 JSP에서 사용하는 코드 대신 쓰는 도구야.

어려운 Java 코드를 안 쓰고, <c:if> 같은 HTML처럼 생긴 명령어를 쓰는 거지!

✅ 예시: JSTL 태그

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<c:if test="${loginId != null}">
  <p>${loginId}님 환영합니다!</p>
</c:if>

이건 자바 코드로 쓰면 if(loginId != null) { … } 와 같은 역할이야.

🧠 JSTL 태그도 결국은 Java 객체다!

<c:if>는 내부적으로 IfTag라는 Java 클래스 객체야.
이 객체가 JSP 실행 시 생성되고 → 조건 체크 → 결과를 출력함.

🔍 2단계. 태그 객체가 매 요청마다 생성되는 구조 설명

📦 JSP 실행 흐름 요약

[사용자가 JSP를 요청함]
→ JSP 내부의 `<c:if>`, `<c:forEach>` 등 태그 발견됨
→ 각각에 대응하는 Java 태그 클래스가 생성됨 (Tag 객체)
→ 조건 처리 또는 반복 수행 후, HTML로 변환됨

✅ 구조도 예시

<jsp>
  <c:forEach>  ← ForEachTag 객체 생성됨
    <c:if>     ← IfTag 객체 생성됨
      ...
    </c:if>
  </c:forEach>
</jsp>

🧠 메모리적으로 중요한 점

항목	설명
태그 객체	JSP 실행 시 매번 생성됨
범위	`request`가 끝날 때 사라짐
GC 대상	JSP 응답이 끝나면 GC가 회수함

→ 즉, 모든 JSTL 태그 객체는 요청마다 생성됨 → GC가 자동 회수

✨ 3단계. 사용자 정의 태그(TagLib)의 메모리 재사용 전략

✅ 사용자 정의 태그란?

💬 개발자가 직접 만든 태그야!

예를 들어, <my:dateFormat /> 같은 걸 만들 수 있어.

✅ 만드는 방법 (기초 구조)

태그 핸들러 클래스 만들기 (TagSupport 상속)
doStartTag(), doEndTag() 등 메서드 구현
.tld 파일로 태그 정의
JSP에서 @taglib으로 불러와서 사용

📦 예시

1. Java 클래스

public class HelloTag extends TagSupport {
    public int doStartTag() {
        try {
            pageContext.getOut().println("안녕하세요!");
        } catch(Exception e) {}
        return SKIP_BODY;
    }
}

2. JSP에서 사용

<%@ taglib prefix="my" uri="/WEB-INF/tlds/mytag.tld" %>
<my:hello />

🧠 사용자 태그는 메모리 재사용 가능할까?

정답: JSP 컨테이너에 따라 다름!

구조	설명
기본 동작	매 요청마다 태그 객체가 생성됨
최적화 전략	태그 객체를 풀(Pool) 로 관리해서 재사용 가능 (Tomcat 기본 최적화)
조건	태그가 상태(state)를 가지지 않아야 함 (즉, 쓰레드 세이프)

✅ 실무 전략

전략	설명
태그 핸들러에 인스턴스 변수 사용 금지	멀티 쓰레드 환경에서 값이 섞일 수 있음
상태 없는 태그 구현	재사용이 가능해서 메모리 효율↑
복잡한 태그는 `SimpleTagSupport` 사용	더 가볍고 깔끔한 구조 제공

🧠 4단계. 면접 포인트 정리

질문	좋은 답변 포인트
JSTL 태그 객체는 메모리에 어떻게 관리되나요?	매 요청마다 생성되고, 요청 종료 후 GC 대상입니다.
사용자 정의 태그 객체는 재사용 가능한가요?	상태가 없다면, 컨테이너가 태그 객체를 재사용할 수 있습니다.
태그 객체가 많아지면 성능에 영향 있나요?	많을수록 GC 부담이 증가하며, 재사용 가능한 구조가 좋습니다.
사용자 태그를 만들 때 주의점은?	쓰레드 안전성 확보 (인스턴스 변수 사용 금지)

✅ 마무리 요약표

항목	설명	메모리 영향
JSTL 태그	매 요청 시 새 객체 생성	GC 대상 (짧은 생명주기)
사용자 태그	기본은 매 요청마다 생성	풀로 재사용 가능 (최적화 시)
태그 재사용 조건	상태 없음 (stateless)	메모리 절약 & 성능 향상

✅ PART 3.3 EL 표현식과 메모리 (중학생도 이해하는 교수급 설명)

🟢 1단계. EL(Expression Language)이 뭐야?

💬 EL은 JSP에서 ${변수명}처럼 간단한 표현식으로 데이터를 출력하거나 비교하는 언어야.

request.getAttribute("id") 대신 ${id}만 쓰면 됨!

✅ 예시

<% request.setAttribute("name", "홍길동"); %>
<p>이름: ${name}</p>

👉 EL은 위에서 `request`, `session` 등의 내장 객체에서 값을 자동으로 찾아줘!

🔍 찾는 순서(우선순위): EL 스코프 탐색 순서

우선순위	스코프	설명
1	PageScope	현재 페이지 안에서만
2	RequestScope	요청(request) 동안만
3	SessionScope	로그인 유지용
4	ApplicationScope	서버 전체 공용

✅ 이 순서대로 변수 찾고, 먼저 찾은 걸 사용함!

🔧 2단계. EL 내부 동작과 캐싱 구조

💬 사용자가 `${member.name}`처럼 EL을 썼을 때 서버 안에서는?

📦 내부 동작 요약

EL 파서가 EL 표현식 파악함 → "${member.name}"
PageScope → RequestScope → Session → ApplicationScope 차례로 탐색
member 객체가 발견되면 → getName() 메서드 호출
결과 값을 HTML로 출력

🧠 EL은 매 요청마다 파싱하지 않는다!

EL은 성능을 위해 내부적으로 표현식을 캐싱함.

→ 자주 쓰는 ${member.name} 같은 표현은 미리 분석해두고 재사용함.

✅ 캐싱 구조의 효과

항목	설명
빠름	같은 표현식을 여러 번 쓰면 파싱 생략
메모리 효율 ↑	분석 결과를 객체로 만들어 재사용
실무 팁	복잡한 EL은 변수로 분리해서 캐싱 효과 극대화 가능

🧠 GC 관점 설명

캐시된 표현식은 JSP의 서블릿 클래스에 저장됨 → 서버가 종료되기 전까지 살아있음
단, EL이 참조하는 객체(request, session)가 사라지면 → EL 결과도 달라짐
EL 캐시 자체는 GC가 잘 정리 못 하므로 과도한 표현식 남용은 주의

🔄 3단계. `<c:forEach>` vs 일반 for문 메모리 차이

✅ 예시 비교

1. JSTL 방식 (`<c:forEach>`)

<c:forEach var="item" items="${list}">
  <p>${item.name}</p>
</c:forEach>

2. 스크립틀릿 방식 (`for`문)

<%
  for(Member m : list) {
%>
  <p><%= m.getName() %></p>
<%
  }
%>

✅ 메모리 비교

항목	`<c:forEach>`	자바 for문 (`<% %>`)
태그 객체 생성	ForEachTag 객체 생성	없음 (단순 루프)
속도	약간 느림 (반복마다 태그 메서드 호출)	빠름
메모리 사용	JSP 내에서 태그 객체, 반복 변수를 매번 생성	지역 변수만 사용
GC 영향	객체 수 많으면 GC 압박 ↑	거의 없음
가독성	높음 (HTML에 가깝고 명확)	낮음 (Java 코드 섞임)
멀티 개발자 환경	👍 디자이너와 협업 쉬움	어려움

🧠 실무 최적화 전략

1000개 이상의 반복 출력처럼 성능이 중요한 경우

→ Java 코드 for문(스크립틀릿) 또는 Ajax 렌더링으로 대체 고려
단순한 반복(10~100건 이하)은 <c:forEach>가 가독성 + 유지보수에 좋음

🎓 4단계. 면접 포인트 정리

질문	좋은 답변 포인트
EL은 어떻게 동작하나요?	4단계 스코프 탐색 → getter 실행 → HTML 출력
EL은 매번 새로 파싱하나요?	아니다. 내부적으로 파싱 캐싱 구조가 있음
`<c:forEach>`는 메모리 효율이 좋은가요?	가독성은 좋지만 반복 시 객체가 생성되어 메모리 사용은 있음
`forEach`와 `for` 중 성능 좋은 건?	순수 Java for문이 빠름. 대량 데이터 출력 시 고려
EL이 GC에 미치는 영향은?	EL 자체는 JSP 클래스에 남아있고, 참조 객체가 사라지면 GC 가능

✅ 마무리 요약표

항목	설명
EL 캐싱 구조	자주 쓰는 표현은 파싱 결과 재사용
EL 탐색 순서	Page → Request → Session → Application
`<c:forEach>`	반복 시 태그 객체 매번 생성 (가독성 👍, 성능은 느릴 수 있음)
일반 for문	빠르지만 코드가 복잡하고 유지보수 어려움

** 📌 PART 3.1 JSP → 서블릿 변환 과정 + 메모리 구조 분석 **

🟢 1단계. JSP는 어떻게 작동할까? (기초 설명)

✅ JSP 실행 순서 요약

🔍 예시

🧠 2단계. JSP → 서블릿 변환 타이밍 (2가지 방식)

💡 왜 precompile이 좋을까?

🧬 3단계. _jspService() 구조 분석

✅ 예시 구조

💡 특징

💾 4단계. JSP가 메모리에 어떻게 보관될까?

✅ 실행 파일 생성 위치

✅ 메모리 구조

📌 GC 관점

✅ 요약: JSP 실행 흐름 한눈에 보기

🎯 실무 성능 고려사항

💡 면접 예상 질문

✅ 마무리 요약표

🟢 1단계. 태그 라이브러리가 뭐야?

✅ 예시: JSTL 태그

🧠 JSTL 태그도 결국은 Java 객체다!

🔍 2단계. 태그 객체가 매 요청마다 생성되는 구조 설명

📦 JSP 실행 흐름 요약

✅ 구조도 예시

🧠 메모리적으로 중요한 점

✨ 3단계. 사용자 정의 태그(TagLib)의 메모리 재사용 전략

✅ 사용자 정의 태그란?

✅ 만드는 방법 (기초 구조)

📦 예시

1. Java 클래스

2. JSP에서 사용

🧠 사용자 태그는 메모리 재사용 가능할까?

✅ 실무 전략

🧠 4단계. 면접 포인트 정리

✅ 마무리 요약표

🟢 1단계. EL(Expression Language)이 뭐야?

✅ 예시

👉 EL은 위에서 request, session 등의 내장 객체에서 값을 자동으로 찾아줘!

🔍 찾는 순서(우선순위): EL 스코프 탐색 순서

🔧 2단계. EL 내부 동작과 캐싱 구조

💬 사용자가 ${member.name}처럼 EL을 썼을 때 서버 안에서는?

📦 내부 동작 요약

🧠 EL은 매 요청마다 파싱하지 않는다!

✅ 캐싱 구조의 효과

🧠 GC 관점 설명

🔄 3단계. <c:forEach> vs 일반 for문 메모리 차이

✅ 예시 비교

1. JSTL 방식 (<c:forEach>)

2. 스크립틀릿 방식 (for문)

✅ 메모리 비교

🧠 실무 최적화 전략

🎓 4단계. 면접 포인트 정리

✅ 마무리 요약표

📌 PART 3.1 JSP → 서블릿 변환 과정 + 메모리 구조 분석

👉 EL은 위에서 `request`, `session` 등의 내장 객체에서 값을 자동으로 찾아줘!

💬 사용자가 `${member.name}`처럼 EL을 썼을 때 서버 안에서는?

🔄 3단계. `<c:forEach>` vs 일반 for문 메모리 차이

1. JSTL 방식 (`<c:forEach>`)

2. 스크립틀릿 방식 (`for`문)