Đồng thờiConcurrency

Semaphoreaka Counting Semaphore, Bulkhead (semaphore-based), Concurrency Limiter

Phát N 'vé' để giới hạn tối đa N tác vụ cùng chạm vào một tài nguyên tại một thời điểm.Hand out N 'tickets' so at most N tasks touch a resource at the same time.

Độ khóDifficulty: VừaMedium
Mức phổ biếnUsage: Mức phổ biếnUsage 4/5
Thời gian đọcReading time: ~9 phút đọc~9 min read

Thảo luậnDiscussion

Ví dụ đời thườngReal-life analogy

Bãi giữ xe ở chung cư chỉ có 50 thẻ. Xe vào phải lấy một thẻ, hết thẻ thì xếp hàng chờ ngoài cổng; xe ra trả thẻ thì xe tiếp theo được vào. Bảo vệ không quan tâm bạn là ai — chỉ đếm thẻ. Ai lấy thẻ mà quên trả thì bãi cứ 'đầy ảo' mãi.An apartment parking lot has only 50 tickets. A car must take a ticket to enter; when they're gone, cars queue at the gate; a car leaving returns its ticket so the next one gets in. The guard doesn't care who you are — he only counts tickets. Anyone who forgets to return a ticket makes the lot 'phantom full' forever.

Vấn đề và giải phápProblem and solution

Không có patternWithout the pattern

Cuối tháng, hệ thống phải xuất 10.000 hoá đơn điện tử qua API của nhà cung cấp, mà họ chỉ cho tối đa 5 kết nối đồng thời. Bạn bắn song song không giới hạn → bị trả 429/503, thậm chí bị khoá API key. Giảm xuống chạy tuần tự thì mất cả buổi. Thread pool riêng cho việc này thì cồng kềnh, và với virtual thread/goroutine, số luồng không còn là thứ cần giới hạn nữa.At month end, the system must issue 10,000 e-invoices through a provider API that allows at most 5 concurrent connections. Fire them all in parallel → 429/503 errors, maybe a blocked API key. Run them sequentially → it takes all afternoon. A dedicated thread pool is clunky, and with virtual threads/goroutines the number of threads is no longer what you need to limit.

Với SemaphoreWith Semaphore

Dùng một semaphore đếm với N giấy phép (permit). Trước khi gọi tài nguyên, tác vụ acquire một permit (hết thì chờ, hoặc chờ có hạn rồi bỏ cuộc); xong việc thì release trong finally/defer. Số tác vụ TỒN TẠI có thể rất lớn, nhưng số tác vụ ĐANG chạm tài nguyên không bao giờ vượt N.Use a counting semaphore with N permits. Before touching the resource, a task acquires a permit (waiting when none are left, or waiting with a timeout and giving up); when done it releases in finally/defer. The number of EXISTING tasks can be huge, but the number CURRENTLY touching the resource never exceeds N.

Thành phần tham giaParticipants

Semaphore: Bộ đếm N permit, chặn khi về 0.A counter of N permits that blocks at zero.
Task (thread/goroutine): Acquire trước khi vào vùng giới hạn, release khi ra.Acquires before entering the limited zone, releases on exit.
Guarded resource: API đối tác, connection DB, RAM, GPU... thứ chỉ chịu được N người dùng cùng lúc.Partner API, DB connections, RAM, GPU... anything that tolerates only N concurrent users.
Wait policy: Chờ vô hạn, chờ có timeout, hay từ chối ngay (fail fast) khi hết permit.Wait forever, wait with a timeout, or reject immediately (fail fast) when no permit is left.

Sơ đồ và luồng thực thiDiagram and execution flow

Dùng Tự chạy hoặc phím mũi tên để đi qua từng bước gọi giữa các object. Console hiển thị output tương ứng của chương trình.Use Autoplay or the arrow keys to step through each call between objects. The console shows the matching program output.

1Semaphore là channel có buffer 2: mỗi ô trống là một permit. Ba goroutine cùng muốn gọi API.The semaphore is a channel with buffer 2: each empty slot is a permit. Three goroutines want to call the API.

← →

console

1sem: 0/2 in use

implementsimplementsextendsextendsgọi / dùngcalls / usestạo racreatesgửi qua channelsends via channel1thứ tự chạy (bấm để nhảy bước)execution order (click to jump)

Code: Java Spring Boot ⇄ GoCode: Java Spring Boot ⇄ Go

Cùng một bài toán, hai ngôn ngữ. Rê chuột hoặc focus vào chú thích (số màu cam) để làm nổi bật dòng code tương ứng.Same problem, two languages. Hover or focus an annotation (orange number) to highlight its line.

JavaSpring Boot 3 · Java 21Spring Boot 3 · Java 21

package com.shop.invoice;

import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import org.springframework.stereotype.Component;

@Component
public class InvoiceGateway {
    // The e-invoice provider allows at most 5 concurrent connections
    private final Semaphore permits = new Semaphore(5, true);1
    private final EInvoiceClient client;

    public InvoiceGateway(EInvoiceClient client) {
        this.client = client;
    }

    public InvoiceNo issue(Invoice invoice) throws InterruptedException {
        if (!permits.tryAcquire(3, TimeUnit.SECONDS)) {2
            throw new GatewayBusyException("e-invoice gateway saturated, retry later");
        }
        try {3
            return client.issue(invoice); // at most 5 threads here at once
        } finally {
            permits.release(); // ALWAYS give the ticket back4
        }
    }

    public int availablePermits() {
        return permits.availablePermits(); // handy for a metrics gauge
    }
}

GoGo 1.23 · thư viện chuẩnGo 1.23 · standard library

package invoice

import (
	"context"
	"log"
	"sync"
)

// A buffered channel with capacity N is a counting semaphore.
type Gateway struct {
	sem    chan struct{}1
	client *EInvoiceClient
}

func NewGateway(client *EInvoiceClient, limit int) *Gateway {
	return &Gateway{sem: make(chan struct{}, limit), client: client}
}

func (g *Gateway) Issue(ctx context.Context, inv Invoice) (string, error) {
	select {
	case g.sem <- struct{}{}: // acquire: blocks while the buffer is full2
	case <-ctx.Done():3
		return "", ctx.Err() // gave up waiting
	}
	defer func() { <-g.sem }() // release, even on error or panic4

	return g.client.Issue(ctx, inv)
}

func (g *Gateway) IssueAll(ctx context.Context, invs []Invoice) {
	var wg sync.WaitGroup
	for _, inv := range invs {
		wg.Add(1)
		go func() { // Go 1.22+: inv is a fresh variable per iteration
			defer wg.Done()
			if _, err := g.Issue(ctx, inv); err != nil {
				log.Printf("invoice %s: %v", inv.ID, err)
			}
		}()
	}
	wg.Wait()
}

Khác biệt chính giữa Java và GoKey differences between Java and Go

01Java có class java.util.concurrent.Semaphore chuyên dụng. Go không có trong stdlib — idiom là channel có buffer make(chan struct{}, N), hoặc golang.org/x/sync/semaphore khi cần permit có trọng số.Java has a dedicated java.util.concurrent.Semaphore class. Go has none in the stdlib — the idiom is a buffered channel make(chan struct{}, N), or golang.org/x/sync/semaphore when you need weighted permits.
02Chờ có giới hạn: Java dùng tryAcquire(timeout); Go dùng select giữa lệnh gửi và ctx.Done() — huỷ và timeout gom chung một cơ chế.Bounded waiting: Java uses tryAcquire(timeout); Go uses select between the send and ctx.Done() — cancellation and timeout share one mechanism.
03Trả permit: Java finally { release(); }, Go defer func() { <-sem }(). Cả hai đều phải đặt NGAY sau khi acquire thành công.Returning a permit: Java finally { release(); }, Go defer func() { <-sem }(). Both must come RIGHT after a successful acquire.
04Spring thường dùng Resilience4j @Bulkhead thay vì Semaphore viết tay. Go hay dùng errgroup.SetLimit(n) khi chỉ cần giới hạn số goroutine của một nhóm việc.Spring apps usually reach for Resilience4j @Bulkhead instead of a hand-rolled Semaphore. Go often uses errgroup.SetLimit(n) when you just need to cap a group's goroutines.

Ứng dụng thực tếReal-world usage

Connection pool (HikariCP, database/sql)Connection pools (HikariCP, database/sql)
maximumPoolSize hay db.SetMaxOpenConns(n) thực chất là một semaphore: hết connection thì request chờ tới connectionTimeout.maximumPoolSize or db.SetMaxOpenConns(n) is essentially a semaphore: out of connections → requests wait up to connectionTimeout.
Resilience4j Bulkhead trong Spring BootResilience4j Bulkhead in Spring Boot
SemaphoreBulkhead cô lập từng downstream: VNPay chậm cũng chỉ chiếm tối đa N luồng, không kéo sập phần còn lại của app.SemaphoreBulkhead isolates each downstream: a slow VNPay can only occupy N threads, it can't drag down the rest of the app.
errgroup.SetLimit và x/sync/semaphoreerrgroup.SetLimit and x/sync/semaphore
Công cụ Go như go build hay các crawler dùng semaphore để giới hạn số tiến trình/kết nối song song.Go tools like go build and crawlers use semaphores to cap parallel processes/connections.
Xuất hoá đơn, gọi API ngân hàng có quotaE-invoicing, bank APIs with quotas
Đối tác (hoá đơn điện tử, cổng ngân hàng, OCR căn cước) giới hạn số kết nối đồng thời theo hợp đồng.Partners (e-invoice providers, bank gateways, ID-card OCR) cap concurrent connections by contract.

Khi nào dùng và khi nào khôngWhen to use it, and when not

Nên dùng khiUse it when

Tài nguyên chỉ chịu được N người dùng CÙNG LÚC (API đối tác, GPU, connection, RAM).A resource tolerates only N users AT ONCE (partner API, GPU, connections, RAM).
Dùng virtual thread/goroutine nên không còn 'thread pool size' tự nhiên để giới hạn.You use virtual threads/goroutines, so there's no natural 'thread pool size' left to limit you.
Muốn cô lập (bulkhead) một downstream chậm để nó không ăn hết tài nguyên của app.You want to isolate (bulkhead) a slow downstream so it can't eat all of the app's resources.

Không nên dùng khiAvoid it when

Giới hạn là theo THỜI GIAN (100 request/giây) — đó là việc của Rate Limiter, không phải semaphore.The limit is per TIME (100 requests/second) — that's a Rate Limiter's job, not a semaphore's.
Chỉ cần bảo vệ dữ liệu dùng chung khỏi ghi đồng thời — dùng Mutex (semaphore 1 permit thì không biết ai đang giữ khoá).You only need to protect shared data from concurrent writes — use a Mutex (a 1-permit semaphore has no notion of an owner).
Nhiều instance cùng chia một quota — semaphore trong bộ nhớ chỉ đếm trong một process; cần giải pháp phân tán (Redis...).Several instances share one quota — an in-memory semaphore only counts within one process; you need a distributed one (Redis...).

Ưu điểmPros

Rất đơn giản, chi phí thấp, chặn quá tải từ phía mình.Very simple, cheap, and stops overload from your side.
Tách 'số tác vụ' khỏi 'số tác vụ đang chạm tài nguyên' — hợp với virtual thread/goroutine.Decouples 'number of tasks' from 'tasks touching the resource' — a great fit for virtual threads/goroutines.
Permit có trọng số mô hình hoá được tài nguyên như RAM, băng thông.Weighted permits can model resources like RAM or bandwidth.

Nhược điểmCons

Quên release (thiếu finally/defer) là rò permit âm thầm, tới lúc về 0 thì cả hệ thống treo.Forgetting release (no finally/defer) silently leaks permits; at zero the whole system hangs.
Semaphore không có chủ: bất kỳ ai cũng release được, kể cả người chưa acquire → đếm sai.A semaphore has no owner: anyone can release, even without acquiring → miscounting.
Chọn N không dễ: nhỏ quá thì lãng phí, lớn quá thì vẫn quá tải.Picking N is hard: too small wastes capacity, too big still overloads.

Anti-pattern: lỗi thường gặpAnti-pattern: common mistake

Acquire không có finally — rò permitAcquire without finally — leaking permits

Chỉ cần client.issue ném exception một lần là permit không bao giờ được trả. Sau 5 lỗi như vậy, semaphore về 0 và mọi request chờ mãi — trông giống deadlock nhưng không có stack trace nào chỉ ra lý do.A single exception from client.issue means the permit is never returned. After 5 such errors the semaphore hits zero and every request waits forever — it looks like a deadlock, yet no stack trace explains it.

public InvoiceNo issue(Invoice invoice) throws InterruptedException {
    permits.acquire();                     // ❌ waits forever, no timeout
    InvoiceNo no = client.issue(invoice);  // ❌ throws → release below never runs
    permits.release();
    return no;
}

Dễ nhầm vớiEasily confused with

Semaphore vs Rate Limiter

Rate limiter đếm theo thời gian (100 req/giây, kể cả khi mỗi req chỉ mất 1ms). Semaphore đếm việc đang chạy (tối đa 5 cùng lúc, bất kể mỗi giây bao nhiêu).A rate limiter counts over time (100 req/s, even if each takes 1ms). A semaphore counts work in flight (at most 5 at once, however many per second).

Semaphore vs Worker Pool

Worker pool giới hạn bằng số worker CỐ ĐỊNH nhận việc từ queue. Semaphore để mỗi tác vụ có goroutine/thread riêng, chỉ chặn ở cửa vào tài nguyên.A worker pool limits via a FIXED number of workers pulling from a queue. A semaphore lets each task have its own goroutine/thread and only gates the resource entrance.

Bài tập áp dụngExercise

Dịch vụ OCR căn cước chạy trên GPU chỉ xử lý được 3 ảnh cùng lúc. Viết hàm Scan(ctx, img) (Go) hoặc scan(img) (Java) đảm bảo tối đa 3 lời gọi song song, chờ tối đa 2 giây rồi trả lỗi 'busy'.An ID-card OCR service runs on a GPU that handles only 3 images at once. Write Scan(ctx, img) (Go) or scan(img) (Java) ensuring at most 3 concurrent calls, waiting at most 2 seconds before returning a 'busy' error.

Kiểm tra kiến thứcKnowledge check

Câu 1 / 5Question 1 of 5

Semaphore giới hạn điều gì?What does a semaphore limit?

Phím 1–4 để chọn đáp án, Enter để kiểm tra.Press 1–4 to choose an answer, Enter to check.

Thẻ ghi nhớFlashcards

Ôn tập ngắt quãng (spaced repetition): thẻ được lặp lại sau 1 → 3 → 7 → 14 → 30 ngày để củng cố trí nhớ dài hạn.Spaced repetition: cards are repeated after 1 → 3 → 7 → 14 → 30 days to build long-term memory.

Dùng trong bài toánUsed in problems

4 bài toán Backend dùng pattern này4 backend problems use this pattern

Pattern liên quanRelated patterns

Worker Pool Rate Limiter Circuit Breaker Producer-Consumer

Bài trướcPrevious

Cancellation / Context

Bài tiếpNext

Rate Limiter

Thảo luậnDiscussion

Semaphoreaka Counting Semaphore, Bulkhead (semaphore-based), Concurrency Limiter

Phát N 'vé' để giới hạn tối đa N tác vụ cùng chạm vào một tài nguyên tại một thời điểm.Hand out N 'tickets' so at most N tasks touch a resource at the same time.

VừaMedium

Mức phổ biếnUsage 4/5

~9 phút đọc~9 min read

package com.shop.invoice; import java.util.concurrent.Semaphore; import java.util.concurrent.TimeUnit; import org.springframework.stereotype.Component; @Component public class InvoiceGateway { // The e-invoice provider allows at most 5 concurrent connections private final Semaphore permits = new Semaphore(5, true);1 private final EInvoiceClient client; public InvoiceGateway(EInvoiceClient client) { this.client = client; } public InvoiceNo issue(Invoice invoice) throws InterruptedException { if (!permits.tryAcquire(3, TimeUnit.SECONDS)) {2 throw new GatewayBusyException("e-invoice gateway saturated, retry later"); } try {3 return client.issue(invoice); // at most 5 threads here at once } finally { permits.release(); // ALWAYS give the ticket back4 } } public int availablePermits() { return permits.availablePermits(); // handy for a metrics gauge } }

package invoice import ( "context" "log" "sync" ) // A buffered channel with capacity N is a counting semaphore. type Gateway struct { sem chan struct{}1 client *EInvoiceClient } func NewGateway(client *EInvoiceClient, limit int) *Gateway { return &Gateway{sem: make(chan struct{}, limit), client: client} } func (g *Gateway) Issue(ctx context.Context, inv Invoice) (string, error) { select { case g.sem <- struct{}{}: // acquire: blocks while the buffer is full2 case <-ctx.Done():3 return "", ctx.Err() // gave up waiting } defer func() { <-g.sem }() // release, even on error or panic4 return g.client.Issue(ctx, inv) } func (g *Gateway) IssueAll(ctx context.Context, invs []Invoice) { var wg sync.WaitGroup for _, inv := range invs { wg.Add(1) go func() { // Go 1.22+: inv is a fresh variable per iteration defer wg.Done() if _, err := g.Issue(ctx, inv); err != nil { log.Printf("invoice %s: %v", inv.ID, err) } }() } wg.Wait() }

public InvoiceNo issue(Invoice invoice) throws InterruptedException { permits.acquire(); // ❌ waits forever, no timeout InvoiceNo no = client.issue(invoice); // ❌ throws → release below never runs permits.release(); return no; }