답변

Go에서 채널은 고루틴 간 데이터 전송을 위한 동기화 수단입니다. 다음과 같은 종류가 있습니다:

• 비버퍼링된 채널 — 데이터가 다른 고루틴에서 수신될 때까지 송신자를 차단합니다.
• 버퍼링된 채널 — 고정된 크기의 내부 버퍼를 보유하고 있습니다. 버퍼가 가득 차기 전까지 송신자는 차단되지 않습니다.

비버퍼링된 채널은 동기화가 중요한 곳에서 유용하며, 송신자와 수신자가 코드의 동일한 위치에서 만나는 것을 보장해야 합니다. 버퍼링된 채널은 데이터 전달에 ‘여유’를 두기 위해 적합하며, 큐, 워커, 비동기 작업 등을 조직하는 데 적합합니다.

예시:

func main() {
    ch := make(chan int) // 비버퍼링된 채널
    go func() {
        ch <- 42 // 수신자가 없을 경우 차단됩니다.
    }()
    fmt.Println(<-ch)

    bufch := make(chan int, 2) // 2 요소의 버퍼링된 채널
    bufch <- 1 // 차단되지 않습니다.
    bufch <- 2 // 차단되지 않습니다.
    // 다음 전송은 읽기가 없으면 차단됩니다.
}

짚고 넘어갈 질문

버퍼링된 채널이 추가 동기화 없이 수많은 생산자와 소비자 간의 큐를 대체할 수 있을까요?

대부분 ‘예’라고 대답합니다. 하지만, 송신 순서의 보장이 중요하지 않거나 메시지가 손실되지 않는 경우에만 가능합니다. 여러 읽는 사람/쓰는 사람의 경우 경쟁 조건과 데이터 손실이 발생할 수 있으므로 동기화 제어는 여전히 필요합니다(작업 풀, 뮤텍스, 채널 닫기를 위한 컨텍스트 등).

주제의 미세한 차이로 인한 실제 오류 사례

---

이야기

로그 처리에서 프로그래머들은 파서와 집계기 간에 이벤트를 전달하기 위해 길이가 1000인 버퍼링된 채널을 사용했습니다. 서비스를 중지할 때 채널을 닫는 것을 잊어서 일부 이벤트가 '잃어버려졌습니다' — 워커가 전체 버퍼를 처리하기 전에 종료되었습니다. 명시적으로 채널을 닫고 모든 내용이 출하될 때까지 차단하여 수정했습니다.

---

이야기

분산 서비스에서 뮤텍스 큐를 버퍼링된 채널로 교체하려 할 때 '멈춘' 송신자 상황을 고려하지 않았습니다: 버퍼가 가득 차면 전송 차단이 결국 전체 시스템을 느리게 하고 타임아웃을 유발했으며, 인터페이스가 '지연'되었습니다. 분석 후 일부 동기화를 조건 변수로 다시 복원했습니다.

---

이야기

원격 측정 모듈에서 모듈과 소비자 간의 오류 로그를 위해 비버퍼링된 채널을 사용했습니다. 처리 지연으로 인해 작성자가 차단되고, 1분 만에 수십만 개의 데이터가 고루틴에 쌓여 '고루틴 초과'가 발생했습니다. 비버퍼링된 채널을 버퍼링된 채널과 비동기 큐 청소 작업자로 교체하여 수정했습니다.