기억을 위한 기록

자료구조 구현체/형태 정렬 순서 보장 중복 허용 탐색 시간 삽입 시간 삭제 시간 특징 및 용도ListArrayList✕OOO(1)O(n)O(n)배열 기반, 인덱스 접근 빠름 LinkedList✕OOO(n)O(1)*O(1)*노드 기반, 중간 삽입/삭제 유리SetHashSet✕✕✕O(1)O(1)O(1)중복 제거, 빠른 포함 여부 확인 LinkedHashSet✕입력 순서✕O(1)O(1)O(1)HashSet + 순서 유지 TreeSetO✕✕O(log n)O(log n)O(log n)정렬 필요 시 사용 (Red-Black Tree)MapHashMap✕✕키 중복 ✕O(1)O(1)O(1)키-값 매핑, 매우 일반적 사용 LinkedHashMap✕입력 순서키 중복 ✕O(1)O(1)O(1)HashMap + 순서 유지 Tr..

1. 개요서비스 운영 중 다음과 같은 에러가 발생했습니다:java.io.IOException: Too many open files lsof -p 명령어로 확인해보니, 특정 프로세스에서 File Descriptor(FD) 가 비정상적으로 증가하고 있음을 확인했습니다. 그 원인은 아래의 코드에 있었습니다.2. 문제의 원인if (Files.isDirectory(path)) { List paths = Files.list(path).collect(Collectors.toList()); size = paths.size();}위 코드에서 Files.list(path) 는 디렉토리의 파일 목록을 스트림 형태로 반환합니다. 하지만 이 스트림은 내부적으로 디렉토리 핸들(파일 디스크립터)을 열고 유지합니다.즉,..

1. 개요운영 환경에서 다량의 요청을 처리하는 과정 중, 특정 프로세스에서 File Descriptor(FD) 초과 오류가 발생증상: Too many open files 오류 다발원인: Netty 기반의 TCP 요청 처리 시, 비정상적으로 많은 FD 및 스레드가 생성됨2. 원인 분석해당 원인은 해당 서비스에서의 Netty 클라이언트의 사용 방식비정상 구조Netty 클라이언트 인스턴스를 매 요청마다 새로 생성하는 방식(prototype)으로 구성됨각 요청 시 마다 내부적으로 다음 자원이 생성됨:TCP 채널96개의 스레드 (Netty 이벤트 루프 그룹 기준)Socket FD📌 예시 (비정상 구조 기준 시나리오)요청 수 생성되는 Netty 스레드 수 예상 FD 수196약 100+1009,600수천 개 이상결..

1. 이슈 개요Apache POI의 SXSSFWorkbook을 사용하는 엑셀 다운로드 서비스에서 임시 파일(xml)이 삭제되지 않고 Tomcat의 tmp 디렉토리에 다량 누적되는 현상이 발견이는 일부 서비스에서 dispose() 호출을 누락한 채 엑셀을 생성하고 있기 때문2. file.deleteOnExit() 동작 및 비권장 이유Apache POI 5.2.0에서는 file.deleteOnExit()의 자동 호출이 기본적으로 제거되었습니다.🔍 deleteOnExit()의 내부 동작JVM 종료 시 삭제할 파일 경로를 내부 List에 저장파일마다 해당 List에 경로가 추가되며 크기 제한이 없음JVM 종료 전까지 삭제되지 않음⚠️ 문제점항목 설명메모리 누수 위험List 크기 제한 없음 → 파일 많이 생성 ..

1. 개요redis를 도입하면서 개발서버 클러스터 구성중 다음과 같은 문제가 발생하였습니다:구성: 마스터 1개 + 슬레이브 2개 + Sentinel 다중 구성증상: Sentinel이 무한 failover를 반복 수행, 마스터가 지속적으로 변경됨2. 원인 분석Sentinel 설정 파일(sentinel.conf)에서, 마스터 Redis의 주소를 다음과 같이 127.0.0.1(Loopback IP) 로 지정되어있는 것이 주요 원인이었습니다.🔍 잘못된 설정 예시...sentinel monitor mymaster 127.0.0.1 6379 2....🚨 문제가 되는 이유: 127.0.0.1 사용 시1️⃣ 다른 노드에서 접근 불가127.0.0.1은 각 서버의 자기 자신을 가리키는 loopback 주소입니다.Sen..

1. 개요기존 시스템에서 운영 중인 모니터링 데몬을 재구동한 직후, 모니터링 값이 비정상적으로 계산되는 현상이 발생2. 문제 원인모니터링 대상 시간값을 static final로 선언하여, 클래스 로딩 시점에 고정된 값이 사용되는 구조private static final String sendDate = LocalDateTime.now().minusMinutes(10) .format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss"));위와 같이 선언된 sendDate는 클래스가 최초 로딩될 때 한 번만 계산되며, 이후 값은 변경되지 않음.데몬 재기동 시점이 바뀌어도, 이미 계산된 값이 재사용되어 현재 시간을 반영하지 못하는 문제가 발생3. 해..