답변.

문맥의 역사:

Goroutine leak는 goroutine이 존재하면서 메모리에 남아 있지만 실제로는 "의미가 없어진" 상황입니다 (계산이 완료되고 데이터가 필요하지 않지만 종료 조건이 없습니다). 이는 메모리 누수와 유사하지만 실행 스레드에 관한 것입니다. 이는 Go에서 매우 중요합니다. 큰 부하는 리소스를 고갈시킬 수 있습니다.

문제:

다른 언어들과 달리, 직접적으로 스레드를 관리하는 것은 종종 수동으로 종료하게 되지만, Go에서는 goroutine을 쉽게 시작할 수 있지만 항상 올바르게 종료되지는 않습니다. 흔한 오류는: 주요 로직이 완료된 후 goroutine이 "멈춰있는" 상태 — 닫힌 채널로부터 데이터를 기다리거나 신호를 아예 받지 못하는 경우입니다.

해결책:

누수를 방지하기 위해 컨트롤 구조를 사용합니다: context, 채널 종료, 신호 변수. 각 goroutine에서의 종료 경로를 미리 설계하고, 정리를 위해 defer를 사용하는 것이 중요합니다. 예:

func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
    for {
        select {
        case <-ctx.Done():
            return
        case job, ok := <-jobs:
            if !ok {
                return
            }
            results <- job * 2
        }
    }
}

주요 특징:

goroutine의 전체 생애주기를 관리하세요.
관리된 종료를 위해 context를 사용하세요.
사용 후 채널을 닫으세요.

까다로운 질문들.

Goroutine을 정지시키기 위해 그냥 채널을 닫는 것이 가능한가요?

항상 그런 것은 아닙니다. select에 다른 case가 있거나 ok를 통해 종료를 확인하지 않으면, goroutine이 "멈춰있게" 될 수 있습니다.

val, ok := <-ch
if !ok { return } // 이렇게 올바릅니다.

select에서 context.Done을 처리하지 않으면 어떤 일이 발생합니까?

Goroutine은 취소되었음을 알지 못하고 "영원히" 남아 있게 됩니다. 이는 누수로 가는 직접적인 경로입니다.

go runtime을 사용하여 leak를 잡을 수 있습니까?

누수를 추적하기 위한 표준 도구는 없습니다. runtime.NumGoroutine을 통해 활성 goroutine 수를 모니터링하거나 타사 라이브러리의 leak detector를 사용해야 합니다.

일반적인 오류 및 안티 패턴

존재하지 않거나 차단된 채널에서 대기하기
종료 경로가 없는 무한 goroutine 실행
채널 종료의 불일치

실생활 예시

부정적인 케이스

푸시 알림 시스템에서 각 들어오는 메시지에 대해 goroutine을 실행하지만, 컨텍스트가 취소되거나 채널이 닫힐 때 이를 종료하는 것을 잊습니다 — 수백 개의 "죽은" goroutine이 메모리에 남아 있습니다.

장점:

쉽게 시작할 수 있으며, 빠른 프로토타입 제작

단점:

메모리 증가
스케줄러 속도 저하

긍정적인 케이스

Goroutine의 작업은 context를 통해 제어되며, 비즈니스 로직 레벨에서 select의 종료를 확인하고, 성공적으로 송신/처리 후 채널을 종료합니다.