Phỏng vấn kỹ thuật Go: Goroutine, Channel và Concurrency

Các câu hỏi phỏng vấn Go về goroutine, channel và concurrency luôn nằm trong nhóm chủ đề thách thức nhất mà ứng viên phải đối mặt. Hiểu sâu các khái niệm này là yếu tố phân biệt kỹ sư Go cấp cao với những người đang học ngôn ngữ. Hướng dẫn này tổng hợp các câu hỏi mà nhà tuyển dụng thường đặt ra trong năm 2026, kèm ví dụ code sẵn sàng cho production và lời giải thích đằng sau mỗi câu trả lời.

Nền tảng Goroutine: Câu hỏi luôn xuất hiện

Vòng đầu tiên của phỏng vấn thường kiểm tra liệu ứng viên có hiểu goroutine thực sự là gì hay không — không chỉ cách khởi tạo chúng.

H: Goroutine là gì và khác với OS thread như thế nào?

Goroutine là hàm concurrent nhẹ được quản lý bởi Go runtime scheduler, không phải hệ điều hành. Go runtime thực hiện multiplexing hàng nghìn goroutine lên một số lượng nhỏ OS thread theo mô hình lập lịch M:N (M goroutine được ánh xạ lên N OS thread).

package main

import (
	"fmt"
	"runtime"
	"sync"
)

func main() {
	// Print the number of OS threads available
	fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))

	var wg sync.WaitGroup

	for i := 0; i < 10000; i++ {
		wg.Add(1)
		go func(id int) {
			defer wg.Done()
			// Each goroutine starts with ~2-8KB stack
			// OS threads typically start with 1-8MB
			_ = id
		}(i)
	}

	wg.Wait()
	fmt.Println("All 10,000 goroutines completed")
}

Sự khác biệt chính cần nêu trong phỏng vấn: goroutine bắt đầu với stack 2-8KB có thể tăng trưởng động, so với stack cố định 1-8MB của OS thread. Việc chuyển đổi ngữ cảnh giữa các goroutine được xử lý ở user space bởi Go scheduler, tránh được chi phí chuyển đổi ngữ cảnh cấp kernel tốn kém của OS thread. Điều này cho phép tạo 100.000 goroutine một cách thực tế, trong khi 100.000 OS thread sẽ làm cạn kiệt tài nguyên hệ thống.

H: Điều gì xảy ra khi một goroutine bị panic?

Một panic chưa được recover trong bất kỳ goroutine nào sẽ làm sập toàn bộ chương trình. Khác với exception trong Java hoặc Python, panic lan truyền lên call stack của chính goroutine đó — không phải stack của goroutine đã tạo ra nó. Cách duy nhất để bắt panic là dùng recover() bên trong deferred function của cùng goroutine đó.

package main

import "fmt"

func safeGo(fn func()) {
	go func() {
		defer func() {
			if r := recover(); r != nil {
				fmt.Println("recovered from panic:", r)
			}
		}()
		fn() // execute the actual work
	}()
}

func main() {
	safeGo(func() {
		panic("something went wrong")
	})

	// Give goroutine time to complete
	select {}
}

Nhà tuyển dụng tìm kiếm nhận thức rằng các dịch vụ Go trong môi trường production đều bao bọc việc khởi chạy goroutine trong pattern recovery. Thư viện như errgroup xử lý việc này một cách gọn gàng hơn.

Ngữ nghĩa Channel: Buffered, Unbuffered và Directional

Các câu hỏi về channel bộc lộ liệu ứng viên thực sự hiểu mô hình concurrency của Go hay chỉ thuộc lòng các pattern.

H: Sự khác biệt giữa buffered và unbuffered channel là gì?

Unbuffered channel (make(chan T)) yêu cầu cả người gửi và người nhận đều sẵn sàng đồng thời — thao tác gửi bị chặn cho đến khi goroutine khác nhận giá trị. Buffered channel (make(chan T, n)) cho phép gửi tối đa n giá trị mà không bị chặn.

package main

import "fmt"

func main() {
	// Unbuffered: send blocks until receive is ready
	ch := make(chan string)
	go func() {
		ch <- "hello" // blocks here until main reads
	}()
	msg := <-ch
	fmt.Println(msg)

	// Buffered: send does not block until buffer is full
	buf := make(chan int, 3)
	buf <- 1 // does not block (buffer has space)
	buf <- 2 // does not block
	buf <- 3 // does not block
	// buf <- 4 would block — buffer is full

	fmt.Println(<-buf, <-buf, <-buf) // 1 2 3
}

Câu hỏi tiếp nối mà nhà tuyển dụng hay đặt: "Khi nào nên chọn loại nào?" Unbuffered channel bắt buộc đồng bộ hóa — hữu ích khi người gửi cần biết người nhận đã xử lý giá trị. Buffered channel tách rời thời gian giữa người gửi và người nhận — hữu ích cho work queue hoặc rate limiting khi có thể chấp nhận một độ trễ nhất định.

H: Điều gì xảy ra khi đóng một channel?

Đóng channel báo hiệu rằng không còn giá trị nào được gửi nữa. Thao tác receive trên channel đã đóng trả về ngay lập tức với zero value. Gửi vào channel đã đóng gây ra panic. Vòng lặp range trên channel tự động thoát khi channel được đóng.

package main

import "fmt"

func producer(ch chan<- int, count int) {
	for i := 0; i < count; i++ {
		ch <- i
	}
	close(ch) // signal: no more values
}

func main() {
	ch := make(chan int, 5)
	go producer(ch, 5)

	// range exits automatically when channel closes
	for val := range ch {
		fmt.Println("received:", val)
	}

	// Reading from closed channel returns zero value + false
	val, ok := <-ch
	fmt.Printf("after close: val=%d, ok=%v\n", val, ok)
}

Điểm quan trọng: chỉ người gửi mới nên đóng channel, không bao giờ là người nhận. Đóng một channel mà goroutine khác vẫn đang ghi vào sẽ gây ra panic.

Câu lệnh Select: Multiplexing Channel

H: select hoạt động như thế nào và điều gì xảy ra khi nhiều case sẵn sàng cùng lúc?

Câu lệnh select chặn cho đến khi một trong các thao tác channel có thể thực hiện. Khi nhiều case sẵn sàng đồng thời, Go chọn ngẫu nhiên — điều này ngăn chặn việc bất kỳ case nào bị bỏ đói.

package main

import (
	"context"
	"fmt"
	"time"
)

func fetchFromAPI(ctx context.Context, url string) (string, error) {
	resultCh := make(chan string, 1)
	errCh := make(chan error, 1)

	go func() {
		// Simulate API call
		time.Sleep(200 * time.Millisecond)
		resultCh <- fmt.Sprintf("data from %s", url)
	}()

	select {
	case result := <-resultCh:
		return result, nil
	case err := <-errCh:
		return "", err
	case <-ctx.Done():
		// Context cancelled or timed out
		return "", ctx.Err()
	}
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
	defer cancel()

	result, err := fetchFromAPI(ctx, "https://api.example.com/data")
	if err != nil {
		fmt.Println("error:", err)
		return
	}
	fmt.Println(result)
}

Nhà tuyển dụng kiểm tra hai điều với select: hiểu biết về quy tắc chọn ngẫu nhiên, và khả năng kết hợp channel với context.Context cho các pattern timeout và hủy bỏ.

Các Pattern Concurrency Phổ biến trong Phỏng vấn

Phỏng vấn Go cấp senior hầu như luôn bao gồm câu hỏi về việc triển khai một trong các pattern sau từ đầu.

Pattern Fan-Out/Fan-In

H: Triển khai pipeline fan-out/fan-in xử lý các item đồng thời.

Fan-out phân phối công việc cho nhiều goroutine. Fan-in tổng hợp kết quả từ nhiều goroutine vào một channel duy nhất.

package main

import (
	"fmt"
	"sync"
)

// generator produces values on a channel
func generator(nums ...int) <-chan int {
	out := make(chan int)
	go func() {
		for _, n := range nums {
			out <- n
		}
		close(out)
	}()
	return out
}

// square reads from input, squares each value
func square(in <-chan int) <-chan int {
	out := make(chan int)
	go func() {
		for n := range in {
			out <- n * n
		}
		close(out)
	}()
	return out
}

// fanIn merges multiple channels into one
func fanIn(channels ...<-chan int) <-chan int {
	var wg sync.WaitGroup
	merged := make(chan int)

	for _, ch := range channels {
		wg.Add(1)
		go func(c <-chan int) {
			defer wg.Done()
			for val := range c {
				merged <- val
			}
		}(ch)
	}

	go func() {
		wg.Wait()
		close(merged) // close after all inputs are drained
	}()

	return merged
}

func main() {
	in := generator(2, 3, 4, 5, 6)

	// Fan out: two goroutines reading from same channel
	c1 := square(in)
	c2 := square(in)

	// Fan in: merge results
	for result := range fanIn(c1, c2) {
		fmt.Println(result)
	}
}

Insight chính mà nhà tuyển dụng mong đợi: channel generator được chia sẻ giữa c1 và c2, nên mỗi giá trị chỉ được xử lý bởi đúng một worker (không bị trùng lặp). Hàm fanIn sử dụng WaitGroup để biết khi nào tất cả các input channel đã được rút hết trước khi đóng channel tổng hợp.

Worker Pool với errgroup

H: Triển khai bounded worker pool có xử lý lỗi như thế nào?

Package golang.org/x/sync/errgroup (thuộc Go extended standard library) giải quyết vấn đề này một cách gọn gàng. Nó quản lý vòng đời goroutine, thu thập lỗi đầu tiên, và tích hợp với context cho việc hủy bỏ.

package main

import (
	"context"
	"fmt"
	"golang.org/x/sync/errgroup"
)

func processItem(ctx context.Context, id int) error {
	// Check for cancellation before heavy work
	select {
	case <-ctx.Done():
		return ctx.Err()
	default:
	}

	if id == 7 {
		return fmt.Errorf("failed to process item %d", id)
	}
	fmt.Printf("processed item %d\n", id)
	return nil
}

func main() {
	g, ctx := errgroup.WithContext(context.Background())
	g.SetLimit(3) // maximum 3 concurrent goroutines

	for i := 0; i < 10; i++ {
		id := i
		g.Go(func() error {
			return processItem(ctx, id)
		})
	}

	// Wait blocks until all goroutines finish
	// Returns the first non-nil error
	if err := g.Wait(); err != nil {
		fmt.Println("pipeline error:", err)
	}
}

Kể từ Go 1.24 (phiên bản stable mới nhất tính đến đầu năm 2026), pattern này vẫn là cách tiếp cận được khuyến nghị. Phương thức SetLimit được thêm vào từ Go 1.20 và loại bỏ nhu cầu tự triển khai giới hạn concurrency dựa trên semaphore.

Race Condition và Các Primitive sync

H: Làm thế nào để phát hiện và ngăn chặn race condition trong Go?

Go cung cấp race detector tích hợp sẵn, kích hoạt bằng flag -race. Công cụ này phát hiện truy cập concurrent không đồng bộ vào shared memory tại thời điểm runtime.

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

// BAD: race condition — do not use in production
func unsafeCounter() int {
	counter := 0
	var wg sync.WaitGroup
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			counter++ // DATA RACE: concurrent read/write
		}()
	}
	wg.Wait()
	return counter // result is non-deterministic
}

// GOOD: atomic operations for simple counters
func atomicCounter() int64 {
	var counter atomic.Int64
	var wg sync.WaitGroup
	for i := 0; i < 1000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			counter.Add(1) // thread-safe atomic increment
		}()
	}
	wg.Wait()
	return counter.Load() // always 1000
}

// GOOD: mutex for complex shared state
type SafeMap struct {
	mu sync.RWMutex
	data map[string]int
}

func (m *SafeMap) Set(key string, val int) {
	m.mu.Lock()         // exclusive lock for writes
	defer m.mu.Unlock()
	m.data[key] = val
}

func (m *SafeMap) Get(key string) (int, bool) {
	m.mu.RLock()         // shared lock for reads
	defer m.mu.RUnlock()
	v, ok := m.data[key]
	return v, ok
}

func main() {
	fmt.Println("unsafe:", unsafeCounter())  // unpredictable
	fmt.Println("atomic:", atomicCounter())  // always 1000
}

Câu trả lời phỏng vấn cần bao gồm ba chiến lược đồng bộ hóa: sync.Mutex / sync.RWMutex cho shared state phức tạp, sync/atomic cho các counter và flag đơn giản, và channel để giao tiếp giữa các goroutine ("share memory by communicating, don’t communicate by sharing memory"). Việc chạy go test -race ./... nên là một phần của mọi CI pipeline.

Context và Pattern Hủy bỏ

H: Giải thích cách context.Context kiểm soát vòng đời goroutine.

Package context cung cấp cơ chế để truyền tín hiệu hủy bỏ, deadline, và các giá trị theo phạm vi request qua các ranh giới goroutine. Mọi goroutine chạy lâu dài đều nên nhận context.Context làm tham số đầu tiên.

package main

import (
	"context"
	"fmt"
	"time"
)

// worker simulates a long-running task
func worker(ctx context.Context, id int, results chan<- string) {
	select {
	case <-time.After(time.Duration(id*100) * time.Millisecond):
		results <- fmt.Sprintf("worker %d: done", id)
	case <-ctx.Done():
		results <- fmt.Sprintf("worker %d: cancelled (%v)", id, ctx.Err())
	}
}

func main() {
	// Parent context with 250ms deadline
	ctx, cancel := context.WithTimeout(context.Background(), 250*time.Millisecond)
	defer cancel()

	results := make(chan string, 5)

	// Launch 5 workers with increasing durations
	for i := 1; i <= 5; i++ {
		go worker(ctx, i, results)
	}

	// Collect all results
	for i := 0; i < 5; i++ {
		fmt.Println(<-results)
	}
}

Worker 1 và 2 hoàn thành trong deadline 250ms. Worker 3, 4 và 5 nhận tín hiệu hủy bỏ qua ctx.Done(). Pattern này là nền tảng để xây dựng HTTP server và microservice bền vững trong Go — mọi request handler đều nhận một context truyền tín hiệu hủy bỏ khi client ngắt kết nối.

Phát hiện Deadlock: Câu hỏi Phỏng vấn Mẹo

H: Đoạn code này có bị deadlock không? Tại sao?

Câu hỏi về deadlock rất phổ biến vì kiểm tra khả năng phân tích việc lập lịch goroutine và các thao tác channel của ứng viên.

package main

func main() {
	ch := make(chan int)
	ch <- 42 // DEADLOCK: unbuffered send with no receiver
	// The main goroutine blocks here forever
	// Go runtime detects this: "fatal error: all goroutines are asleep"
}

Cách khắc phục đơn giản: biến channel thành buffered (make(chan int, 1)) hoặc tạo một goroutine để nhận trước khi gửi. Go runtime phát hiện deadlock khi tất cả goroutine bị chặn — nhưng chỉ khi tất cả goroutine đều ngủ. Nếu dù chỉ một goroutine đang chạy (ví dụ, một HTTP server chạy ngầm), runtime sẽ không phát hiện deadlock từng phần.

Pattern Nâng cao: Xử lý Concurrent với Rate Limiting

H: Triển khai rate-limited concurrent API call như thế nào?

Câu hỏi này kiểm tra khả năng kết hợp nhiều primitive concurrency thành một giải pháp thống nhất.

package main

import (
	"context"
	"fmt"
	"sync"
	"time"
)

// RateLimiter controls concurrent and temporal access
type RateLimiter struct {
	semaphore chan struct{}   // limits concurrency
	ticker    *time.Ticker    // limits rate
}

func NewRateLimiter(maxConcurrent int, interval time.Duration) *RateLimiter {
	return &RateLimiter{
		semaphore: make(chan struct{}, maxConcurrent),
		ticker:    time.NewTicker(interval),
	}
}

func (rl *RateLimiter) Execute(ctx context.Context, fn func() error) error {
	// Wait for rate limit tick
	select {
	case <-rl.ticker.C:
	case <-ctx.Done():
		return ctx.Err()
	}

	// Acquire concurrency slot
	select {
	case rl.semaphore <- struct{}{}:
	case <-ctx.Done():
		return ctx.Err()
	}

	defer func() { <-rl.semaphore }() // release slot
	return fn()
}

func main() {
	rl := NewRateLimiter(3, 100*time.Millisecond)
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func(id int) {
			defer wg.Done()
			err := rl.Execute(ctx, func() error {
				fmt.Printf("[%v] processing %d\n", time.Now().Format("04:05.000"), id)
				time.Sleep(150 * time.Millisecond) // simulate work
				return nil
			})
			if err != nil {
				fmt.Printf("item %d: %v\n", id, err)
			}
		}(i)
	}
	wg.Wait()
}

Pattern này kết hợp semaphore dựa trên channel (để giới hạn concurrency) với ticker (để giới hạn tốc độ). Double select với kiểm tra context đảm bảo shutdown một cách graceful. Câu trả lời sẵn sàng cho production như thế này là yếu tố phân biệt ứng viên cấp senior.

Kết luận

• Goroutine là thread user-space được Go runtime quản lý với lập lịch M:N; luôn recover panic trong các goroutine được spawn
• Unbuffered channel đồng bộ hóa người gửi và người nhận; buffered channel tách rời thời gian — chọn dựa trên việc người gửi có cần xác nhận hay không
• Câu lệnh select multiplexing các thao tác channel với lựa chọn ngẫu nhiên khi nhiều case sẵn sàng; kết hợp với context.Context cho timeout
• Fan-out/fan-in và worker pool (qua errgroup.SetLimit) là hai pattern concurrency được hỏi nhiều nhất
• Sử dụng sync.Mutex cho shared state phức tạp, sync/atomic cho counter đơn giản, và channel cho giao tiếp goroutine
• Luôn chạy go test -race trong CI để bắt data race; deadlock từng phần cần pprof để chẩn đoán
• Không lưu context.Context vào struct — truyền nó làm tham số đầu tiên của hàm
• Rate limiting trong Go kết hợp semaphore channel với ticker, bao bọc trong select statement có nhận thức context