** 📌 PART 2.1 DAO / DTO / Service 구조의 의존성 관리 + 메모리 최적화 전략 **

---

🟢 1단계. DAO / DTO / Service가 뭔지 아주 쉽게 설명

이름	역할	비유
DAO (데이터 접근 객체)	DB랑 대화하는 역할	“데이터 베이스 전화기”
DTO (데이터 전달 객체)	데이터를 옮기는 상자	“택배 상자”
Service (비즈니스 로직 처리)	로직 판단, 처리 흐름 담당	“매니저”

---

✅ 예시로 쉽게 보기

[사용자] → 글쓰기 버튼 클릭
 → [Controller] → "글 저장해줘!"
 → [Service] → "글이 유효한지 먼저 체크하자"
 → [DAO] → DB에 INSERT 요청
 → [DTO] → 글 제목/내용을 하나로 포장해서 전달

---

🧠 DAO 인스턴스 생성 전략

💬 문제: DAO를 계속 new 하면 메모리 낭비

BoardDao dao = new BoardDao();  // 💣 이걸 요청마다 하면 메모리 낭비

💡 해결책: 싱글톤 패턴(Singleton Pattern)

✨ 딱 한 개만 만들고, 모두가 그걸 쓰게 하는 패턴이야!

---

🔧 싱글톤 패턴 구조 (중학생도 이해 가능!)

public class BoardDao {
    // 💡 딱 한 개만 생성되는 객체 저장소
    private static BoardDao instance = new BoardDao();

    // 💡 외부에서 new 못하게 막음 (생성자 private)
    private BoardDao() {}

    // 💡 이걸로만 접근 가능
    public static BoardDao getInstance() {
        return instance;
    }
}

---

✅ 장점 (면접 포인트 포함)

항목	설명
메모리 절약	객체를 딱 1개만 생성
GC 효율	중복 객체 생성 없음 → GC 줄어듦
성능 향상	매번 new 할 필요 없음
의존성 관리	어디서든 동일한 객체 사용 가능

🧠 면접 예상 질문

왜 DAO는 싱글톤으로 만들까요?

→ 자주 쓰는 객체라 계속 생성하면 메모리 낭비 + 성능 저하가 발생해서!

---

🧠 DB 커넥션 풀(Connection Pool, CP)의 메모리 최적화 원리

💬 먼저 개념부터 쉽게 설명

• DB에 접속하려면 커넥션 객체를 만들어야 해
• 이게 비쌈! (시간도 오래 걸리고, 메모리도 많이 씀)

그래서 커넥션을 미리 여러 개 만들어 놓고

요청 올 때마다 꺼내 쓰고 다시 돌려주는 풀(pool)을 만들어 놓은 것!

---

🎯 커넥션 풀 비유

방식	설명	비유
매번 new	요청마다 DB 접속 새로 생성	매번 공구 사는 공장
커넥션 풀	DB 접속 여러 개 만들어두고 재사용	공구 대여소 만들기! 필요할 때 빌려 쓰고 돌려줌

---

💻 커넥션 풀 동작 구조

[프로그램 시작 시]
→ 커넥션 10개 미리 만들어둠

[사용자 요청 시]
→ 하나 꺼내서 DAO에서 사용 → 끝나면 다시 반납

[메모리 효율 👍]
→ 불필요한 커넥션 생성/파괴 없이 고정된 리소스로 처리 가능

---

✅ 실무 사용 예시: DBCP / HikariCP / TomcatCP

• Tomcat, Spring, MyBatis 등에서 모두 기본으로 사용함
• XML이나 config에서 커넥션 풀 개수 설정 가능 (maxActive, initialSize 등)

---

✅ 커넥션 풀 도입의 메모리 / GC 장점

항목	효과
커넥션 객체 재사용	매번 생성할 필요 없음 → 메모리 낭비↓
GC 부담 감소	자주 생성/삭제 되는 객체가 줄어듦
응답 속도 향상	DB 연결 시간이 줄어듦

---

🧠 면접 포인트 정리

질문	요점
DAO를 왜 싱글톤으로 만들까요?	불필요한 객체 생성 줄여서 성능, 메모리 절약
커넥션 풀을 쓰면 뭐가 좋은가요?	메모리 절약, 성능 향상, GC 부담 감소
커넥션 풀을 안 쓰면 어떤 일이 생기나요?	커넥션 객체가 매번 생성 → GC 부담 + 서버 다운 위험
DAO가 너무 많아지면 어떻게 하나요?	공통 로직 추상화 (GenericDAO 또는 Repository 패턴 적용)

---

✅ 마무리 요약표

요소	설계 전략	메모리 최적화 포인트
DAO	싱글톤	중복 객체 제거, 재사용
DTO	가볍게 설계, 불변 객체 사용	필요 시 GC 대상, 생성 최소화
Service	요청마다 생성 가능 (상태 없음)	비즈니스 로직만 수행
Connection	풀로 관리	객체 재사용 → 메모리 안정

✅ PART 2.2 JDBC 커넥션 & 리소스 누수 방지 전략

“데이터베이스랑 연결할 때 메모리 낭비 없이, 보안도 잘 지키는 방법”

---

🟢 1단계. JDBC 연결이 뭐야?

💬 아주 쉽게 말하면:

Java에서 DB랑 대화하려면 전화선을 연결해야 해.

이 전화선을 JDBC 커넥션(Connection) 이라고 불러.

---

📦 JDBC 기본 흐름 요약

Connection conn = null;
PreparedStatement pstmt = null;
ResultSet rs = null;

try {
   conn = DriverManager.getConnection(...);   // 📞 전화 연결
   pstmt = conn.prepareStatement("SELECT * FROM member");  // 💬 말하기 준비
   rs = pstmt.executeQuery();                 // 📥 결과 받기
   while(rs.next()) { ... }                   // 🔁 결과 반복
} catch(Exception e) {
   e.printStackTrace();
} finally {
   rs.close(); pstmt.close(); conn.close();   // 🧹 마무리 정리!
}

---

🔥 2단계. 리소스 누수가 뭐야?

💣 리소스 누수(Resource Leak)란

DB 커넥션, Statement, ResultSet 같은 것들을

쓰고 나서 닫지 않아서 메모리를 계속 잡아먹는 현상이야.

---

🧠 왜 위험할까?

• 커넥션이 안 닫히면, DB 입장에서 전화선이 계속 붙잡혀 있음
• 서버에는 커넥션 수 제한이 있음 → 폭주 시 DB 다운 가능
• GC가 객체를 수거하지 못하고 메모리 터짐(OutOfMemoryError)

---

✅ 3단계. try-with-resources로 자동으로 닫기!

💬 이 기능은 Java 7부터 추가된 “자동 정리 기능”이야!

💡 try문에서 AutoCloseable 인터페이스를 구현한 객체는

try가 끝나면 자동으로 close()가 호출돼!

---

✅ 예제 코드 (옛날 방식 vs 최신 방식 비교)

// 🧹 최신 try-with-resources 방식
try (
   Connection conn = DriverManager.getConnection(...);
   PreparedStatement pstmt = conn.prepareStatement("...");
   ResultSet rs = pstmt.executeQuery();
) {
   while(rs.next()) { ... }
} catch(Exception e) {
   e.printStackTrace();
}
// ✅ rs, pstmt, conn 모두 자동으로 닫힘!

---

✅ 장점

항목	효과
코드 깔끔	try 블록 하나로 close 처리
안전성 ↑	예외 발생해도 자동으로 정리됨
메모리 안정	GC 대상이 됨 → 누수 방지

🧠 면접 포인트

try-with-resources를 안 썼을 때 ResultSet 안 닫히면 GC가 수거 못해요

→ GC는 “접근 불가능한 객체”만 정리함 → 연결된 리소스는 남음

---

🧠 4단계. Statement / ResultSet 메모리 해제 타이밍

객체	해제 시점	주의점
Connection	반드시 제일 마지막에 닫아야 함	연결 끊기
Statement / PreparedStatement	쿼리 끝나면 닫기	SQL 실행 도구
ResultSet	next() 반복문 끝나고 닫기	결과 메모리 클 수 있음!

GC 관점 요약

• close()를 직접 호출 → 내부에서 DB 소켓, 버퍼 등도 정리
• 안 닫으면 GC가 참조 중이라 메모리 수거 대상이 아님!

---

🔐 5단계. PreparedStatement 재사용 + 보안 + 메모리 전략

---

📌 개념 먼저 설명

String sql = "SELECT * FROM member WHERE id = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "hong");
ResultSet rs = pstmt.executeQuery();

🔎 왜 좋을까?

항목	설명
보안	SQL Injection 방지 (입력값을 문자로 escape 처리)
속도	SQL을 미리 컴파일 해둬서 실행 속도↑
메모리	반복 실행 시 PreparedStatement를 재사용하면 메모리 낭비 ↓

---

☠️ 나쁜 예시: 문자열로 SQL 만들기

String sql = "SELECT * FROM member WHERE id = '" + userInput + "'";
// 👿 SQL Injection 공격에 뚫림!

---

💡 면접에서 나올 질문 정리

질문	핵심 답변 요약
JDBC 자원을 언제 닫아야 하나요?	사용이 끝난 직후, 역순으로 close() 해야 합니다
try-with-resources의 장점은?	코드 간결 + 자동 close + 예외 처리 안정성
ResultSet을 안 닫으면 어떤 문제가 생기나요?	메모리 릭, 커넥션 누수, 성능 저하
PreparedStatement를 사용하는 이유는?	SQL Injection 방지 + 성능 + 메모리 절약
Connection을 재사용하는 방법은?	커넥션 풀(Connection Pool) 사용 (예: HikariCP)

---

✅ 요약 마무리 표

항목	설명	메모리 영향
try-with-resources	자동으로 close() 호출	리소스 누수 방지
PreparedStatement	미리 SQL 컴파일 + ? 바인딩	성능 ↑, 보안 ↑
close 순서	ResultSet → Statement → Connection	GC가 바로 정리 가능하게

✅ PART 2.3 DTO 객체의 설계 관점

“DTO를 어떻게 만들어야 빠르고, 안전하고, 메모리 낭비도 없을까?”

---

🟢 1단계. DTO가 뭐야?

📦 정의 (쉽게)

DTO(Data Transfer Object)는 말 그대로

데이터를 한 덩어리로 옮기기 위한 상자 같은 역할을 해.

예시

public class Member {
    private String id;
    private String name;
    private int age;

    // getter, setter 등
}

→ Member라는 DTO를 만들어서, 컨트롤러 ↔ DB ↔ 뷰 간에 데이터를 주고받을 수 있어.

---

✨ A. Serializable vs Jackson: 왜 쓰고, 성능은 어떤 차이?

---

✅ 1. Serializable 이란?

💬 자바 객체를 그대로 파일, 네트워크, 세션에 저장할 수 있게 만드는 기능

🔧 사용 예시:

public class MemberDTO implements Serializable {
    private String id;
    private String name;
}

📦 사용하는 곳:

• HttpSession에 객체 저장
• 파일에 저장하거나 전송할 때

---

✅ 작동 방식 (쉽게)

[자바 객체] → (Serializable) → [0과 1의 형태로 변환] → 저장/전송

---

🧠 단점

항목	설명
속도 느림	Reflection 기반 직렬화는 무겁고 비효율적
크기 큼	필요 없는 정보까지 같이 저장됨
보안 낮음	민감한 필드까지 그대로 노출 가능

---

✅ 2. Jackson 이란?

💬 Jackson은 자바 객체를 JSON 형태로 바꿔주는 라이브러리야.

예시:

ObjectMapper mapper = new ObjectMapper();
String json = mapper.writeValueAsString(member); // 객체 → JSON

---

✅ Jackson 장점

항목	설명
빠름	커스터마이징된 직렬화 방식으로 성능 좋음
가벼움	JSON 포맷이 작고 가볍다
확장성 ↑	외부 API, 프론트엔드와 연결 시 매우 유리

---

✅ 성능 비교 요약 (면접 핵심)

항목	Serializable	Jackson
사용 목적	세션 저장, 네트워크 전송	JSON 응답, API 통신
속도	느림 (내장 방식)	빠름 (최적화 라이브러리)
포맷	바이너리 (0,1)	JSON (문자열)
가독성	없음	있음 (사람도 읽기 쉬움)
GC 영향	무거움	상대적으로 적음

---

✨ B. 불변 객체(Immutable DTO): 왜 만들고, 메모리엔 어떤 영향?

---

✅ 1. 불변 객체란?

💬 한 번 만들어지면 절대 값이 바뀌지 않는 객체

예시: (Immutable DTO)

public class Member {
    private final String id;
    private final String name;

    public Member(String id, String name) {
        this.id = id;
        this.name = name;
    }

    public String getId() { return id; }
    public String getName() { return name; }
}

---

🧠 왜 좋을까?

장점	설명
안전성 ↑	값을 바꿀 수 없어서 동시 처리(멀티쓰레드)에 강함
오류 ↓	어디서 값이 바뀌는지 추적 안 해도 됨
GC 유리	복잡한 참조 관계가 없음 → 빨리 GC 대상이 됨
캐싱 최적화	같은 내용의 객체는 재사용 가능 → 불필요한 객체 생성을 줄임

---

반대 예시 (Mutable DTO)

member.setName("변경됨");  // 🔥 다른 곳에서 갑자기 바뀌면 추적 어려움

---

✅ 2. 메모리(GC) 관점에서 왜 유리한가?

항목	불변 객체	가변 객체
참조 복잡도	낮음	높음
GC 회수 속도	빠름	느림
객체 재사용	가능	어려움

→ 불변 객체는 참조 트리(tree)가 단순해서 GC가 빨리 수거할 수 있어!

---

✅ 면접 질문 요약 & 정답 포인트

질문	핵심 답변
Serializable을 언제 사용하나요?	세션 저장, 파일 전송처럼 객체 전체를 저장할 때
Jackson을 왜 쓰나요?	JSON 통신용 객체 변환, 빠르고 가벼움
불변 객체의 장점은?	안전성 ↑, 버그 ↓, GC 대상 빠름
DTO에 setter가 없으면 안 되나요?	대부분 필요 없음, 생성자로 값 주입이 안전함
DTO 객체가 많아지면 성능에 영향 있나요?	GC 대상이 많아지므로 설계를 최적화해야 함

---

✅ 마무리 요약표

항목	설명	메모리 측면
Serializable	객체를 바이너리로 저장	무거움, 느림
Jackson	객체 ↔ JSON 문자열	가볍고 빠름
Immutable DTO	값이 절대 안 바뀜	안전성 ↑, GC 유리
Setter 없는 DTO	값이 한 번만 들어감	버그 위험 ↓, 재사용 ↑