** 📌 PART 5.1 파일 업로드의 메모리 문제와 최적화 전략 **

“파일을 올릴 때 서버 메모리가 터지지 않도록 안전하게 처리하는 법”

---

🟢 1단계. 파일 업로드가 뭐야?

💬 사용자가 내 컴퓨터에 있는 사진이나 문서를

웹 사이트에 첨부해서 서버로 보내는 기능이야.

<form method="POST" enctype="multipart/form-data">
  <input type="file" name="photo" />
  <input type="submit" value="업로드" />
</form>

---

✅ 이걸 서버가 받으려면?

• 일반 request.getParameter()로는 파일을 받을 수 없음 ❌

• 대신 파일 데이터가 포함된 특별한 요청인

  "multipart/form-data"를 처리할 수 있어야 해!

  → 이것을 Multipart 요청 처리라고 해요.

---

📦 2단계. MultipartRequest란? (cos.jar or commons-fileupload)

---

✅ cos.jar 사용 예시 (가장 쉬움)

MultipartRequest multi = new MultipartRequest(
   request,
   "C:/upload/",      // 업로드 경로
   10 * 1024 * 1024,  // 최대 업로드 용량 (10MB)
   "UTF-8"
);

---

✅ 처리 흐름

1. 파일 업로드 요청이 들어옴
2. MultipartRequest가 요청을 파싱함
3. 파일은 서버 하드디스크(경로)에 저장됨
4. 일반 텍스트는 메모리에서 처리됨

---

💾 3단계. 임시 파일 저장 vs 메모리 저장 차이점

---

구분	설명	메모리 영향
임시 파일 저장	파일 내용을 서버의 하드디스크에 저장	메모리 사용량 적음 ✅
메모리 저장	작은 파일(text, 필드 값 등)은 메모리에 저장	너무 많으면 GC/메모리 터짐 위험 ❌

---

✅ 업로드할 때 파일이 어디에 저장될까?

• 텍스트 데이터 (예: name=홍길동) → request 메모리 내부
• 파일 (예: photo.jpg) → 지정한 경로 하드디스크

---

💥 문제: 큰 파일을 계속 올리면?

서버는 요청을 파싱하기 전에 전체 요청 데이터를 메모리에 읽게 되는데,

파일이 너무 크거나 동시에 너무 많이 올라오면 → 메모리 부족 오류 발생!

---

😱 오류 예시: java.lang.OutOfMemoryError: Java heap space

---

🧠 4단계. 큰 파일 업로드 시 메모리 폭발 방지 전략

---

✅ 전략 1: 업로드 크기 제한 설정

// 최대 10MB까지 업로드 가능
MultipartRequest multi = new MultipartRequest(
   request,
   "C:/upload/",
   10 * 1024 * 1024, // 10MB
   "UTF-8"
);

✅ 너무 큰 파일은 거부해서 서버를 지킴!

---

✅ 전략 2: 업로드 경로를 외부 디스크로 분리

• 업로드된 파일은 C:/upload/ 같은 하드디스크에 저장되므로

  → 메모리가 아닌 디스크 공간 사용으로 GC 부담 ↓

---

✅ 전략 3: commons-fileupload 사용 + 스트리밍 업로드 방식

Apache commons-fileupload는 요청을 한 줄씩 읽으면서 처리할 수 있음

→ 전체 파일을 메모리에 올리지 않아도 됨!

---

✅ Streaming 방식 예시 흐름 (중요)

1. 요청이 들어오면 → InputStream으로 한 줄씩 읽기
2. 메모리에 쌓지 않고 → 바로 하드디스크에 쓰기
3. 용량 상관없이 안정적으로 업로드 가능!

---

✅ 전략 4: Tomcat의 업로드 설정 제한하기 (web.xml or server.xml)

<!-- web.xml -->
<multipart-config>
   <max-file-size>10485760</max-file-size> <!-- 10MB -->
   <max-request-size>20971520</max-request-size> <!-- 20MB -->
</multipart-config>

→ 서버 차원에서도 방어!

---

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

질문	모범 답변 요약
MultipartRequest는 메모리를 어떻게 사용하나요?	텍스트는 메모리에, 파일은 디스크에 저장합니다
큰 파일 업로드 시 왜 OOM이 발생하나요?	메모리로 전체 요청을 읽으려다 용량 초과
메모리 폭발 방지 전략은?	크기 제한 + 스트리밍 처리 + 디스크 저장 경로 분리
cos.jar vs commons-fileupload 차이는?	cos는 간단, commons는 성능/확장성 우수
업로드 용량 설정은 어디서 하나요?	MultipartRequest 코드, web.xml, 또는 Tomcat 설정에서

---

✅ 마무리 요약표

항목	설명	메모리 효과
MultipartRequest	요청을 파싱하고 파일 저장	큰 파일은 디스크로 처리
텍스트 필드	메모리 저장	다량 요청 시 GC 부담 ↑
업로드 제한	max size 설정	OOM 방지, 성능 안정
스트리밍 업로드	InputStream 처리	메모리 사용 거의 없음 ✅

✅ PART 5.2 다운로드 시 파일 스트림 버퍼링 전략

“파일을 빠르고 안전하게 전송하면서 서버 메모리도 보호하는 법”

---

🟢 1단계. 파일 다운로드 구조부터 이해하자

💬 파일 다운로드란, 서버에 저장된 파일을

브라우저에 전송해서 사용자가 받을 수 있도록 하는 기능이야.

---

✅ 흐름 요약

1. 사용자가 다운로드 버튼 클릭
2. 서버가 파일을 읽음 (InputStream)
3. 사용자에게 전송함 (OutputStream)

---

📦 JSP/Servlet 다운로드 기본 코드 예시

File file = new File("C:/upload/sample.pdf");
FileInputStream in = new FileInputStream(file);
OutputStream out = response.getOutputStream();

byte[] buffer = new byte[4096];
int length;

while ((length = in.read(buffer)) != -1) {
    out.write(buffer, 0, length);
}

---

🔍 2단계. Stream 직접 처리 vs ByteBuffer 차이점

---

✅ 방식 1: Stream 직접 처리 (위 코드처럼)

• InputStream으로 읽고, OutputStream으로 바로 씀
• byte[] buffer를 만들어서 데이터를 조각조각 전달함

장점

• 메모리 적게 씀 (버퍼로 나눠서 전송)
• 간단한 구조, 대부분 이 방식 사용

---

✅ 방식 2: ByteBuffer 사용 (NIO 기반 고성능 방식)

Path path = Paths.get("C:/upload/sample.pdf");
ByteBuffer buffer = ByteBuffer.allocate(8192); // 8KB

try (SeekableByteChannel channel = Files.newByteChannel(path)) {
    while (channel.read(buffer) > 0) {
        buffer.flip();
        out.write(buffer.array(), 0, buffer.limit());
        buffer.clear();
    }
}

장점

• NIO(Non-blocking IO) 기반 → 성능 우수
• 대용량 처리에 강함
• GC 효율적 (DirectBuffer 사용 가능)

---

✅ 성능/메모리 비교 요약표

항목	Stream 방식	ByteBuffer(NIO) 방식
속도	중간	빠름 (NIO 최적화)
코드 간단성	👍 매우 쉬움	설정 복잡
메모리 효율	보통 (heap 사용)	높음 (heap 밖에서 처리 가능)
실무 사용	일반 웹에서는 Stream	대용량/고성능 시스템에서 NIO 사용

---

💾 3단계. flush() / close()의 역할과 메모리 누수 방지 전략

---

✅ flush()

💬 버퍼에 쌓인 데이터를 한 번에 내보내는 역할

• write()만 하면 실제 전송 안 될 수 있음
• flush()를 해줘야 → 네트워크로 전송됨!

out.flush(); // 💡 이거 꼭 해줘야 클라이언트가 파일을 완전히 받음!

---

✅ close()

💬 파일 스트림을 완전히 닫고, 리소스를 해제하는 메서드

• 안 하면 → 스트림이 계속 살아있어서 메모리 누수 발생
• 특히 파일 스트림은 OS 자원을 점유함!

in.close();
out.close();

---

🧠 실무 메모리 누수 방지 핵심 전략

전략	설명
try-with-resources 사용	자동으로 close() 호출됨
flush() → close() 순서 지키기	안 하면 파일 일부 누락 가능
대용량은 반드시 buffer 사용	버퍼 없이 처리 시 메모리 폭주 가능
로그 출력 제한	다운로드 중 너무 많은 로그 출력은 GC 압박 발생

---

✅ try-with-resources 사용 예시 (추천 방식)

try (
    FileInputStream in = new FileInputStream(file);
    OutputStream out = response.getOutputStream();
) {
    byte[] buffer = new byte[8192];
    int len;
    while ((len = in.read(buffer)) != -1) {
        out.write(buffer, 0, len);
    }
    out.flush();
} catch (Exception e) {
    e.printStackTrace();
}

→ 자동으로 close() 호출됨 → 메모리 안전 ✅

---

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

질문	모범 답변 요약
파일 다운로드는 어떻게 처리하나요?	InputStream으로 읽고, OutputStream으로 클라이언트에 전송합니다
ByteBuffer는 언제 쓰나요?	고성능, 대용량 다운로드에서 사용합니다 (NIO 기반)
flush()는 왜 필요하나요?	버퍼에 있는 데이터를 네트워크로 강제 전송합니다
close() 안 하면 어떤 문제가 생기나요?	파일 핸들이 열려 있어 GC가 정리 못 하고 메모리 누수 발생
try-with-resources의 장점은?	close 누락 없이 자동 리소스 정리 → 메모리 안전성 ↑

---

✅ 마무리 요약표

항목	설명	메모리 영향
Stream 방식	일반 다운로드 처리	buffer 크기만큼만 메모리 사용
ByteBuffer 방식	고성능 NIO 기반	direct memory 활용으로 GC 부담 ↓
flush()	버퍼 → 클라이언트 전송	전송 누락 방지
close()	자원 해제	안 하면 누수 발생
try-with-resources	자동 close	메모리 안정성 최고 👍