Compound action: từng method an toàn, ghép lại vẫn hỏng

Bài cuối của phần Concurrency, và là lỗi rất hay gặp ở Order Service: mọi thứ "thread-safe" mà logic vẫn sai.

1. Bài toán

Người dùng bấm "Thanh toán" 2 lần liên tiếp (hoặc client retry). Hai Tomcat thread cùng xử lý đơn 42:

@Service
class PaymentSessionService {
    private final ConcurrentHashMap<Long, PaymentSession> sessions = new ConcurrentHashMap<>();

    PaymentSession start(Long orderId) {
        if (!sessions.containsKey(orderId)) {                 // check
            sessions.put(orderId, createSession(orderId));    // act
        }
        return sessions.get(orderId);
    }
}

2. Vấn đề

Mỗi method containsKey, put đều thread-safe. Nhưng giữa hai lời gọi có một khe hở:

T1: containsKey(42) → false
                           T2: containsKey(42) → false
T1: put(42, session1)
                           T2: put(42, session2)   ← đè, tạo 2 session ở payment gateway

Đây gọi là compound action (thao tác ghép). Thread-safe ở mức method không có nghĩa thread-safe ở mức logic.

3. Giải pháp

Theo thứ tự ưu tiên:

1. Thao tác gộp atomic có sẵn: computeIfAbsent, putIfAbsent, merge, compute, AtomicXxx.compareAndSet.
2. Bọc cả chuỗi trong cùng một khóa khi không có method gộp sẵn.
3. Tránh hẳn state chia sẻ: immutability, thread confinement.
4. Dữ liệu ở DB hoặc nhiều instance: giải ở DB (unique constraint, atomic UPDATE, lock) như Bài 3.5.

4. Code từng bước

Bước 1: Check-then-act → computeIfAbsent

PaymentSession start(Long orderId) {
    return sessions.computeIfAbsent(orderId, this::createSession);   // chỉ tạo 1 lần
}

Bước 2: Read-modify-write → merge/compute/Atomic

counts.merge(status, 1, Integer::sum);
paidAmount.compute(userId, (k, v) -> v == null ? amount : v.add(amount));

AtomicInteger counter = new AtomicInteger();
counter.incrementAndGet();
stateRef.compareAndSet(State.PENDING, State.PAID);

Bước 3: Không có method gộp → cùng một khóa

Vector<Task> tasks = ...;
synchronized (tasks) {               // Vector dùng chính nó làm lock
    if (!tasks.isEmpty()) {
        last = tasks.get(tasks.size() - 1);
    }
}

Mọi chỗ truy cập dữ liệu đó phải dùng cùng một khóa. Khóa một chỗ, quên một chỗ là vô ích.

Bước 4: Nhiều instance → DB

-- unique constraint: chỉ 1 session ACTIVE mỗi đơn
CREATE UNIQUE INDEX ux_session_active ON payment_session(order_id) WHERE status = 'ACTIVE';

-- atomic UPDATE thay cho đọc rồi ghi
UPDATE orders SET status = 'PAID' WHERE id = 42 AND status = 'PENDING';   -- 0 dòng = đã xử lý

Test: bắn 2 request cùng lúc.

curl -s -X POST localhost:8080/orders/42/pay & curl -s -X POST localhost:8080/orders/42/pay & wait
# trước: 2 sessionId khác nhau
# sau:   cùng 1 sessionId

5. Cách hoạt động

containsKey + put (2 bước, có khe hở)
 T1: [lock b][check][unlock] ......... [lock b][put][unlock]
 T2: ........ [lock b][check][unlock] ........ [lock b][put][unlock]
                       ↑ khe hở: T2 chen vào

computeIfAbsent (1 bước, khóa bao trọn)
 T1: [lock bucket(42)][check → null → create → put][unlock]
 T2:                   ⏳ chờ ............................ [lock][check → có rồi → trả session1][unlock]

6. So sánh

7. Khi nào nên dùng / không nên dùng

• Nên: mỗi khi thấy "if rồi làm", "đọc rồi ghi" trên dữ liệu chung, dừng lại hỏi: có thread khác chen vào giữa được không?
• Không nên: làm IO lâu bên trong computeIfAbsent hay khối khóa; tin rằng "dùng class thread-safe là đủ"; khóa JVM khi có nhiều instance.

Bị, vì khóa chỉ bao từng method. Ví dụ lấy phần tử cuối:

Vector<Task> tasks = ...;
Task last = tasks.get(tasks.size() - 1);

A: size() → 10
                   B: remove(0)        → size 9
A: get(9)          ← ArrayIndexOutOfBoundsException

Đó là lý do Vector/Hashtable bị xem là "thread-safe giả": an toàn cấu trúc bên trong, nhưng không bảo vệ logic của bạn. Sửa bằng cách bọc cả chuỗi trong synchronized (tasks) như Bước 3.

Có. Race condition chỉ xảy ra khi có dữ liệu chia sẻ và có thể thay đổi. Bỏ một trong hai là hết.

Immutability: không cho đổi

public record Money(BigDecimal amount, String currency) {
    public Money add(Money other) {
        return new Money(amount.add(other.amount), currency);   // tạo object mới
    }
}
List<String> roles = List.of("ADMIN", "USER");   // immutable

private final AtomicReference<PaymentConfig> config = new AtomicReference<>(load());
void reload() { config.set(load()); }   // reader thấy config cũ hoặc mới, không bao giờ nửa vời

Thread confinement: không chia sẻ

• Biến local trong method: mỗi thread có stack riêng, luôn an toàn.
• Spring bean singleton nên stateless: không giữ state của request trong field.
• ThreadLocal (Bài 3.8): mỗi thread một bản. Nhưng pool tái sử dụng worker, quên remove() thì request B đọc được context của request A. Luôn set trong try, remove() trong finally. ThreadLocal cũng không tự đi theo sang supplyAsync.

@Service
class ReportService {
    // SAI: field dùng chung giữa mọi request
    // private List<Row> rows = new ArrayList<>();

    Report build(Long id) {
        List<Row> rows = new ArrayList<>();   // ĐÚNG: biến local
        ...
    }
}

Không có câu trả lời "càng nhỏ càng tốt". Đây là bài toán lock granularity:

• Khóa phải bao trọn cả compound action, không được nhỏ hơn.
• Nhưng không làm IO, gọi API, query DB lâu trong khi giữ khóa. Chuẩn bị bên ngoài, chỉ khóa đoạn đọc–ghi state.
• Khóa theo key nếu các key độc lập (mỗi orderId một khóa), như ConcurrentHashMap.compute đã làm sẵn.
• Cần nhiều khóa thì luôn lấy theo thứ tự cố định để tránh deadlock (Bài 3.6).

Q1. Dùng toàn class thread-safe thì code có thread-safe không?

🇻🇳 Tiếng Việt:

Không chắc. Mỗi method thread-safe không có nghĩa chuỗi method thread-safe. Ví dụ if (!map.containsKey(k)) map.put(k, v) trên ConcurrentHashMap, hay vector.get(vector.size() - 1), đều có khe hở giữa hai lời gọi. Đó là compound action: check-then-act, read-modify-write. Em xử lý bằng thao tác atomic có sẵn như computeIfAbsent, merge, AtomicInteger; nếu không có thì bọc cả chuỗi trong cùng một khóa.

🇬🇧 English:

Not necessarily. Thread-safe methods do not make a sequence of calls thread-safe. For example, checking containsKey and then calling put on a ConcurrentHashMap, or calling get with size minus one on a Vector, leaves a gap between the two calls. These are compound actions such as check-then-act and read-modify-write. I use built-in atomic operations like computeIfAbsent, merge or AtomicInteger, and if none exists I guard the whole sequence with the same lock.

Q2. Làm sao tránh phải đồng bộ?

🇻🇳 Tiếng Việt:

Bỏ chia sẻ hoặc bỏ thay đổi. Dùng object immutable như record, List.of; giữ state trong biến local; Spring bean singleton phải stateless. Khi buộc phải khóa thì khóa bao trọn compound action, giữ khóa ngắn, không gọi IO trong khóa, và lấy nhiều khóa theo thứ tự cố định. Khi có nhiều instance thì dùng DB constraint hoặc atomic UPDATE.

🇬🇧 English:

Remove either sharing or mutability. Use immutable objects such as records or List.of, keep state in local variables, and keep singleton Spring beans stateless. When locking is unavoidable, the lock must cover the whole compound action, be held briefly, never wrap I/O, and multiple locks must be taken in a fixed order. With several instances we rely on database constraints or atomic updates.

Cách nhớ ngắn gọn

• An toàn từng method ≠ an toàn cả chuỗi.
• Check-then-act → computeIfAbsent; read-modify-write → merge/Atomic.
• Không chia sẻ (local, stateless) hoặc không thay đổi (immutable) thì khỏi khóa.
• Khóa bao trọn, ngắn, không IO, thứ tự cố định; nhiều instance → DB.

Tổng kết phần Concurrency

Khi gặp một bài toán đa luồng, hỏi theo thứ tự: có cần chia sẻ không → có cần thay đổi không → có thao tác atomic sẵn không → khóa bao trọn, ngắn, thứ tự cố định → nhiều instance thì khóa ở DB/distributed. Và nhớ: thread pool, @Async, CompletableFuture chỉ quyết định chạy ở thread nào, không làm dữ liệu chung an toàn hơn.