이벤트를 발행했을 때 스프링은 어떻게 적합한 리스너들을 바로 찾아서 이벤트를 트리거할 수 있는 걸까.이번 글에서는 이벤트 리스너의 정의 방식과 이벤트 발행 시 적합한 리스너를 찾기 위한 과정을 알아보자.이벤트 리스너의 정의 방식스프링에서 이벤트를 구독하고 처리하는 리스너를 정의하는 방식은 크게 두 가지로 나뉜다.1. ApplicationListener 인터페이스 구현하기스프링 초기부터 제공된 ApplicationListener 인터페이스를 구현해서 쓰는 방식이다.이 방식은 리스너와 이벤트가 일대일로 바인딩 된다는 한계가 있다.이벤트 개수만큼 리스너 클래스를 만들어줘야 한다는 것인데 이렇게 하면 클래스가 너무 많아진다는 단점이 있다.@Componentpublic class OrderNotificationL..

최초 회원가입자의 회원 가입일(DATETIME)을 찾는 경우 SQL을 어떻게 작성할 수 있을까-- order by + limit nSELECT m.DATETIME from Member m order by m.DATETIME limit 1;-- MIN()SELECT MIN(m.DATETIME) from Member m;위의 두 가지 쿼리를 떠올릴 수 있다.이 두 쿼리는 인덱스의 존재 여부에 따라 나눠서 살펴볼 필요가 있다.인덱스가 없는 경우1. order by + limit n정렬 기준 컬럼에 인덱스가 안 걸려있는 경우에 order by + limit n 쿼리는 테이블의 전체 데이터를 한번씩은 읽어야 한다.limit n이 있다면 모두 읽어야 한다는 점은 변함이 없지만 전체를 정렬할 필요는 없어진다.전체 정..

효율적인 GC를 위한 도구들가비지 컬렉션이라는 작업은 서버가 메모리를 적절히 관리하면서 돌아갈 수 있도록 해주지만, 잘 설계되지 않는다면 오히려 서버가 요청을 처리하는 데에 방해가 될 수 있다.그래서 이 작업을 효율적으로 할 수 있도록 여러 도구들이 쓰인다.CSetGC 발생 시 정리 대상인 region들의 목록으로, Collection Set의 줄임말이다.G1(Garbage-First)이라는 취지대로 쓰레기가 많은 region을 먼저 정리해야 하고 MaxGCPauseMillis(최대 멈춤 시간, 보통 200) 내로 GC를 끝내야 하므로 모든 region을 대상으로 GC를 할 수는 없다.그래서 모든 Young region을 CSet에 포함하되, Mixed GC를 할 때는 MaxGCPauseMillis 안에..

자바는 객체를 위주로 돌아가는 언어인데 이 객체들은 힙에 저장된다.내가 저장하는 객체들이 어떻게 저장되어 있는지 알아볼 필요가 있다.시작하기에 앞서 JDK 9부터 기본 GC로 G1 GC가 사용되고 있다.그래서 이 글은 G1 GC를 기반으로 한다.Heap은 이렇게 나뉜다일단 힙은 여러 구역으로 나뉜다.G1 GC도 기존의 GC들이 그랬듯이 Eden, Survivor, Old 가 있고, 기존 GC들과 다른 점이 있다면 거대 객체를 저장하기 위한 Humongous가 있다.또 하나 다른 점이 있다면, 기존에는 위와 같이 각 영역들이 고정된 크기로 연속된 주소에 있었지만 G1 GC는 단순히 수천 개의 region으로 분할하여 사용한다.위 이미지에 보이는 조각들이 모두 각각 하나의 region이다.이 region들은..

무려 2년 전에 생성된 이슈다.잘 돌아가던 CI가 간헐적으로 실패하기 시작했다.CI가 터지는 이유는 빌드 과정에서 테스트가 하나 실패하고 있기 때문이었다. 당시에는 스터디 서비스를 새로 개발하던 시기라서 당장 급한 신규 기능 구현에 집중해야 했고, 그래서 해당 테스트에 @Disabled를 붙여두기로 했다.실패하는 테스트는 '일자기준으로_주문목록_조회시_조회된다'라는 테스트였는데, 조회 기능이 문제없이 잘 동작하기도 했기 때문에 @Disabled를 붙여둔 이 테스트는 깃허브에 이슈만 생성된 채로 잊혀졌고 2년이나 지나서 원인을 파악하게 되었다.문제 상황로컬에서 빌드를 할 때는 단 한 번도 테스트 때문에 실패한 적이 없었다.실패한 경우는 모두 Github Actions에서 빌드될 때였다.한 가지 특징적이었던..

같은 MySQL이라도 스토리지 엔진에 따라 제공하는 락의 종류가 다르고 동작 방식도 다르다.이전에 기본 스토리지 엔진이었던 MyISAM이 테이블 기반의 락을 제공했던 것과 달리,InnoDB는 레코드 기반의 락을 제공한다.테이블 기반 락은 단 하나의 레코드가 필요할 때도 테이블 전체를 잠그는 것을 말하는데, 당연히 비효율적인 방식이다.이와 달리 레코드 기반 락은 필요한 레코드만, 혹은 범위로 락을 적용할 수 있다.이를 granularity가 높다고 하는데, 세밀하게 락을 걸 수 있다는 의미로 받아들이면 된다.이렇게 granularity가 높아지면 동시성 측면에서 이점이 있다. 조금 더 자세히 보면, "row 자체를 잠그는 것이 아니고 인덱스 레코드를 잠그는 것"이다.이 표현이 처음에는 되게 헷갈리는 포인트..

센트리에서 CannotCreateTransactionException이 발생했다는 메일이 왔다.트랜잭션 생성을 못한다는 것은 서버가 죽지는 않았어도 사실상 식물인간 상태라는 의미이기 때문에 꽤 중대한 예외라고 생각해서 바로 서버의 로그를 열어봤다.2026-06-10T09:51:52.043+09:00 WARN 1 --- [pool-3-thread-1] com.zaxxer.hikari.pool.PoolBase : HikariPool-1 - Failed to validate connection org.postgresql.jdbc.PgConnection@11111111 (This connection has been closed.). Possibly consider using a shorter ..

많은 서비스에서 사용되는 MySQL은 5.5 버전부터 InnoDB를 기본 스토리지 엔진으로 사용하고 있다.이 InnoDB에서는 인덱스를 어떻게 관리하는지, 쿼리가 들어왔을 때는 어떻게 인덱스를 활용하는지를 알아보고자 한다.인덱스의 종류인덱스는 크게 두 가지로 나뉜다.clustered index와 secondary index다.Clustered Index먼저 clustered index는 테이블에서 단 하나만 존재하는데, 주로 기본 키(primary key)가 이에 해당한다.단 하나만 존재한다고 해서 꼭 하나의 column으로만 이루어져야 하는 것은 아니고 composite key처럼 두 개 이상의 column으로 구성된 하나의 조합이 clustered index가 될 수도 있다. 이 clustered i..