01 RaceCondition

1. Race condition

1. RaceCondion

• 여러 스레드나 프로세스가 동시에 공유 자원에 접근할 때, 실행 순서나 타이밍에 따라 프로그램의 결과가 달라지는 상태
• “누가 먼저 실행되느냐에 따라 결과가 달라지는 문제”
• 동시성(concurrency) 환경에서 주로 발생하며, 예측 불가능하고 디버깅이 어려움

2. 특징

• 공유 자원 접근: 여러 스레드/프로세스가 같은 변수, 메모리, 파일 등을 동시에 읽고 쓸 때 발생
• 결과 불확정: 실행 순서에 따라 프로그램 결과가 달라짐
• 발견 어려움: 항상 발생하지 않고 특정 타이밍에서만 발생하기 때문에 디버깅이 어려움

3. 예시

int count = 0;

Thread1: count = count + 1;
Thread2: count = count + 1;

• Thread1과 Thread2가 동시에 실행되면, count가 1만 증가하거나 2가 되어야 하지만
• 메모리 접근 타이밍에 따라 1만 증가하는 Race condition이 발생할 수 있음

4. 해결방법

• 동기화(synchronization): synchronized, mutex, lock 등을 사용
• 원자적 연산(atomic operation): AtomicInteger 같은 클래스 사용
• 불변 객체 사용(immutable objects): 상태 변경을 막아 Race condition 방지

2. note

1. 2025.09.03. SFTP 연동 문제

개념은 알고는 있었으나, 문제가 없는 로직을 그대로 사용한거라 환경이 바뀌면서 발생하는 것을 인지하지 못했던 일

1. 스프링 스케줄러를 사용중에 RestAPI로 전환함.

• 진행 로직은 영업부서에서 우리 OS에 파일을 넣으면, AP가 있는 파드에서 기존 파일을 지우고, DAT파일 가져와서 읽는 구조
• 스프링 스케줄러에서 문제가 없고, 그냥 실행만 변경하는 건으로 기존 배치 로직을 그대로 가져와서 사용

2. 문제

• 테스트 과정에서 거의 문제가 없었고 극히 희박하게 연동중에 원인을 알 수 없는 오류가 발생함.
• 근데 다시 진행하면 문제가 없어 AP로 Reqeust주는곳도 신규 시스템이라 그쪽 문제라고 추정해서 바톤이 핑퐁함.

3. 원인

• 후행에서 진행한 스레드가 본인의 요청을 처리하기 위해 기존 파일을 지우는 상황 + 선행에서 작업 완료한 파일을 이동하는 과정에서 발생함.
• 스프링 스케줄러를 사용할때 단일 pod에서 큐로 순차적으로 진행해서 문제가 없었음.
• DEV환경에서는 순차적으로 수동으로 버튼 1개씩 눌러서 실행하다보니 처리속도가 더빨라서 인지를 하지 못함.(스프링 스케줄러랑 비슷한 상황이됨)
• PRD에서는 4개 파드가 동시 작동하기 때문에, 약간의 시간차에서 발생함.

4. 해결

• 파드에서 연동 파일을 읽을때 특정 파일만 읽고 있는데, 지울때 전체를 지우지말고 특정 파드만 지우도록 변경.
• 스레드에서 공통된 자원을 사용하는 경우 가능한 명확한 타겟을 설정하는 작업이 필요할듯.

5. note-note

• A파드에서 스레드락을 걸어도, B파드에서는 다른 AP라 적용이 안되는 부분이 있어서 스레드락은 생각을 안했는데 뭔가 좋은 방법이 있을 것 같은데..