코드 저장소.

목차1.쓰게 된 이유2.ArrayList 의 내부 구조3.LinkedList 의 내부 구조4.ArrayList vs LinkedList5.마치며 1.쓰게 된 이유최근에 자료구조와 알고리즘을 공부를 하면서 코딩 테스트를 풀고 있던 도중에 타인의 풀이를 보면서 코드를 분석을 하는 과정에서 간혹 보면 자료구조를 실제로 구현을 해서 풀었던 내용을 본 적이 있었습니다. 그러던중 문득 실제로 코드에 자주 나오는 List, Map의 내부 구조가 궁금해지기 시작했습니다. 이번 글에서는 그중 List부터 보려고 합니다. 이번에는 자주 사용이 되는 ArrayList와 LinkedList의 JDK의 내부 구조를 보면서 어떻게 작동이 되는지 그리고 실제 코드를 직접 구현해 보려고 합니다. 2.ArrayList 의 내부 구조..

목차1.작성 계기2.테스트 시나리오 및 셋팅3.테스트4.결론 1.작성 계기지금까지의 부하 테스트는 일정 생성 요청 하나를 쉬지 않고 반복하는 스트레스 테스트였습니다. "최대 몇 TPS까지 견디는가"를 확인하며 시스템의 한계점을 찾는 데 집중했습니다. 하지만 실제 사용자는 한 API만 연속으로 호출하지 않고, 한 계정으로 초당 수백 번씩 요청하지도 않습니다. 지금까지의 테스트는 한계점 측정이었을 뿐, 실제 트래픽과는 거리가 있었습니다. 그래서 실제 사용 패턴에 가까운 부하 테스트를 위해 여러 API 혼합(Mixed-Flow), 요청 사이 대기 시간(Think-time), 계정별 로그인 세션, 가정 기반 목표 TPS라는 네 가지 요소를 넣어 테스트를 새로 구성했습니다.2.테스트 시나리오 및 셋팅2-1.기존 ..

목차1.지난 글의 문제점2. 개선 방향 검토3.적용4.CAS 회귀 테스트 1.지난 글의 문제점1-1. 재현 테스트에서 드러난 격차 5편에서 리마인더 DELETE 원인 수정과 테스트 데이터 정리를 마친 뒤 재현 테스트를 진행했고 결과는 기대 이상이었습니다.지표4차5차Average1463ms278msMax5153ms1435ms에러율0.00%0.00%Throughput55.83/sec249.2/sec표를 보면 Average는 5배, Throughput은 4배 이상 개선되었습니다. 그런데 이 좋은 결과가 새로운 계산을 하나 요구했습니다.생성 속도: 249.2건/초폴러 이론상 드레인 속도: 33.3건/초 (3초마다 100건)249.2 ÷ 33.3 ≈ 7.5배 생성 속도가 폴러 드레인 속도의 7.5배에 달했습니다...

목차1. 지난 글에서의 재검토와 원인 분석2. 검증3.결론 1. 지난 글에서의 재검토와 원인 분석3차 결과, 다시 들여다보기3차 테스트에서 에러율은 32.30% → 6.13% → 0.0%까지 떨어졌습니다. 트랜잭션 길이를 줄인 조치(인덱스 추가, 카테고리 캐싱, 리마인더 AFTER_COMMIT 분리)가 정확히 목표했던 효과를 냈고, 붕괴 패턴도 더 이상 관측되지 않았습니다.그런데 이 좋은 소식 뒤에 새로운 문제가 숨어 있었습니다. Outbox Pending Backlog가 0 → 약 900건까지 급등한 것입니다. 1, 2차에서는 backlog가 최대 75건 정도까지만 튀었던 걸 감안하면, 확연히 다른 규모였습니다. 같은 시간대 Scheduler Avg Duration도 폴러 1회 실행당 최대 7.5초까..

목차 1.기존의 한계점2.가설3.테스트4.결론 1.기존의 한계점지난 부하 테스트에서 90VU까지 부하를 올렸을 때, 원래는 Outbox 이벤트의 처리 여부를 Kafka 발행 콜백(whenComplete)에서만 판단했다. 별도의 선점 단계 없이, 폴러가 미발행 이벤트를 가져와 바로 Kafka로 보내고, 콜백이 성공하면 그제서야 sent=true가 되는 구조였습니다. 그리고 당시의 성능 수치는 아래의 표와 같습니다. 지표값처리량84.3TPS에러율8.04%평균 응답시간1225ms붕괴 시점테스트 시작 후 약 1분 37초에 붕괴 변경 전 JPA dirty-check 기반// OutboxEventEntitypublic void markSent() { this.sent = true; this.sentA..

목차1.문제2.문제해결과정3.타인의 코드분석 1.문제 2.문제해결과정2-1.문제 요구사항각 작업의 (요청부터 종료까지 걸린 시간)의 평균을 구해, 최소 정수값(소수점 이하 버림)을 반환하는 알고리즘 구현을 하는 것이 목적핵심 스케줄링 규칙하드디스크는 한 번에 하나의 작업만 수행 가능현재 시점에 요청이 들어와 있는 작업들 중 소요 시간이 가장 짧은 작업을 우선 처리실행 가능한 작업이 없다면, 다음 작업이 요청될 때까지 대기요청 시점이나 소요 시간이 같은 작업이 여러 개일 경우 처리 순서는 임의 지정 가능입력: jobs 배열 (각 요소는 [요청시점(s), 소요시간(l)] 형태)작업 개수: 1 \le jobs의 길이 \le 500요청 시점 s: $0 \le s \le 1,000소요 시간 l: 1 \le..