고루틴과 채널은 golang에서 가장 핵심적인 기능 중 하나입니다.
다만 꼼꼼하게 체크하고 사용하지 않으면 여러가지 문제들을 만들어낼 수 있습니다. 그 중 하나는 Close된 채널에 값을 전달하는 상황인데요. 이런 경우 Application은 panic으로 종료하게 됩니다.
panic: send on closed channel
goroutine 1 [running]:
main.main()
/tmp/sandbox2358964969/prog.go:19 +0xfc
우선 간단한 방법으로 이를 예방할 수 있는데요. 채널에 값을 보내기 전 채널로 아래 safeCheck
함수와 같이 채널의 Close 여부를 체크하고, 결과에 따라서 값의 송신 여부를 결정하면 됩니다.
func safeCheck(ch <-chan string) bool {
select {
case <-ch:
return false
default:
}
return true
}
테스트를 해보면 이런 느낌이죠.
package main
import "fmt"
func safeCheck(ch <-chan string) bool {
select {
case <-ch:
return false
default:
}
return true
}
func main() {
c := make(chan string)
fmt.Printf("channel status: %v\n", safeCheck(c))
close(c)
fmt.Printf("channel status: %v\n", safeCheck(c))
}
/*
$ ./chantest
channel status: true
channel status: false
*/
다만 저 방식도 온전한 방식은 아닙니다. 만약 true를 리턴한 찰나에 채널이 close 되버리면 똑같이 panic이 발생할 수 있습니다. (어느정도는 보호되겠지만 간헐적으로 나올 수 있겠죠)
그래서 저렇게 체크하는 코드에 의존하는 것 보단 채널의 상태를 코드단에서 확실하게 컨트롤하는게 더 좋은 방법이란 생각이 듭니다.
package main
import (
"fmt"
"time"
)
func safeCheck(ch <-chan string) bool {
select {
case <-ch:
return false
default:
}
return true
}
func main() {
c := make(chan string)
go func(ch chan string) {
// receive
fmt.Println(<-ch)
// close(ch) 이거보단...
}(c)
go func(ch chan string) {
// send
if safeCheck(ch) {
ch <- "abcd"
close(ch) // 이게 더 좋아보여요
}
}(c)
time.Sleep(time.Second * 2)
}
만약 송/수신이 1:1 관계라면 송신쪽에서 close 여부를 결정하는게 더 좋을 것 같고, 만약 1:n, n:n 관계라면 그냥 안닫고 main 루틴에게 맡기거나 송신자들 간의 합의 이후 close를 하는게 좋다고 생각됩니다. 중복 close를 막기 위해선 mutex 등의 대안이 있을 것 같네요.
매번 고민하지만 사실 답은 잘 모르겠습니다. 다만 이 글은 비개발인 저의 의견이니 참고만 해주세요 😊