Pattern QuestDesign Pattern · Java ⇄ GoDesign Patterns · Java ⇄ Go

#postgresql
#performance
#sql
#spring-boot
#java

Giải quyết deadlock PostgreSQL: 5 nguyên nhân và cách phòng tránhPostgreSQL deadlocks: 5 common causes and how to prevent them

Deadlock khiến query PostgreSQL treo. Bài viết liệt kê nguyên nhân thường gặp và đưa ra giải pháp thực tiễn cho Java Spring Boot.Deadlocks stall PostgreSQL queries. This post lists common causes and gives practical fixes for Java Spring Boot apps.

8 tháng 11, 2026November 8, 20264 phút đọc4 min read000

Mục lụcContents· 11

Khi nào deadlock xuất hiện?
5 lỗi thường gây deadlock trong PostgreSQL
Cách phát hiện nhanh
Giải pháp thực tiễn cho Spring Boot 3 + Java 21
1. Đảm bảo thứ tự truy cập thống nhất
2. Giảm phạm vi transaction
3. Retry khi deadlock xảy ra
4. Tối ưu chỉ mục
5. Tránh mức cô lập SERIALIZABLE nếu không cần
Quy tắc vàng
Tóm tắt

Khi nào deadlock xuất hiện?#

Bạn đang review một ticket: "Đơn hàng bị mất cập nhật khi đồng thời người dùng A và B chỉnh sửa cùng một đơn". Trong log PostgreSQL có dòng deadlock detected. Đó là dấu hiệu classic: hai transaction đang giữ lock trên các row khác nhau và chờ nhau giải phóng, tạo vòng vô hạn.

Deadlock: Khi hai (hoặc nhiều) transaction mỗi bên giữ một lock và chờ lock của bên còn lại, PostgreSQL sẽ phát hiện và abort một trong số chúng.

5 lỗi thường gây deadlock trong PostgreSQL#

Thứ tự lock không thống nhất – Transaction 1 cập nhật bảng orders rồi order_items; Transaction 2 ngược lại. Khi chúng chạy đồng thời, lock trên orders và order_items bị chặn nhau.

Giải quyết deadlock PostgreSQL: 5 nguyên nhân và cách phòng tránh · Pattern Quest

@Transactional

Java

@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepo;
    private final OrderItemRepository itemRepo;

    @Transactional
    public void updateOrder(Long orderId, OrderDto dto) {
        // Luôn cập nhật orders trước, rồi mới order_items
        Order order = orderRepo.findByIdForUpdate(orderId);
        order.setStatus(dto.status());
        orderRepo.save(order);

        for (OrderItemDto itemDto : dto.items()) {
            OrderItem item = itemRepo.findByIdForUpdate(itemDto.id());
            item.setQuantity(itemDto.qty());
            itemRepo.save(item);
        }
    }
}

Java

@Component
@RequiredArgsConstructor
public class DeadlockRetryTemplate {
    private final OrderService orderService;

    public void executeWithRetry(Long orderId, OrderDto dto) {
        int attempts = 0;
        while (true) {
            try {
                orderService.updateOrder(orderId, dto);
                break; // success
            } catch (DataAccessException ex) {
                if (ex.getRootCause() instanceof PSQLException psql &&
                    "40P01".equals(psql.getSQLState())) {
                    attempts++;
                    if (attempts > 5) throw ex;
                    try {
                        Thread.sleep((long) (100 * Math.pow(2, attempts)));
                    } catch (InterruptedException ignored) {}
                } else {
                    throw ex;
                }
            }
        }
    }
}

When does a deadlock happen?#

You are reviewing a ticket: "Order updates get lost when users A and B edit the same order simultaneously". In the PostgreSQL logs you see deadlock detected. That's the classic sign: two transactions each hold a lock on different rows and wait for the other to release, creating a circular wait.

Deadlock: When two (or more) transactions each hold a lock that the other needs, PostgreSQL detects the cycle and aborts one of them.

5 common causes of deadlocks in PostgreSQL#

Inconsistent lock order – Transaction 1 updates orders then order_items; Transaction 2 does the opposite. When they run concurrently, the lock on orders and order_items block each other.
Oversized transactions – Packing many INSERT/UPDATE/DELETE statements into a single @Transactional method. The longer a transaction holds locks, the higher the collision chance.
Unnecessary SELECT … FOR UPDATE – Taking an exclusive lock on a row you only read later wastes a lock.
Missing or wrong indexes – PostgreSQL scans whole pages to locate rows, locking many pages and increasing the chance of deadlock with other transactions.
Isolation level SERIALIZABLE – The highest isolation keeps broader locks, which amplifies deadlock risk.

Quick ways to spot a deadlock#

pg_stat_activity – run SELECT pid, usename, query, state FROM pg_stat_activity WHERE state='active'; to see which transactions are waiting for a lock.
log_min_error_statement = deadlock – enable this to get a stack trace whenever PostgreSQL aborts a transaction.
EXPLAIN (ANALYZE, BUFFERS) … – inspect the execution plan and verify which indexes are used.

Practical fixes for Spring Boot 3 + Java 21#

1. Enforce a consistent lock ordering#

Java

@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepo;
    private final OrderItemRepository itemRepo;

    @Transactional
    public void updateOrder(Long orderId, OrderDto dto) {
        // Always lock orders first, then order_items
        Order order = orderRepo.findByIdForUpdate(orderId);
        order.setStatus(dto.status());
        orderRepo.save(order);

        for (OrderItemDto itemDto : dto.items()) {
            OrderItem item = itemRepo.findByIdForUpdate(itemDto.id());
            item.setQuantity(itemDto.qty());
            itemRepo.save(item);
        }
    }
}

findByIdForUpdate runs a SELECT … FOR UPDATE. By always acquiring the lock on orders before order_items, concurrent transactions wait at the same spot instead of forming a cycle.

2. Keep transactions short#

If a service method only reads, annotate it with @Transactional(readOnly = true). For writes, split unrelated steps into separate methods, each with its own small @Transactional.

3. Retry on deadlock#

PostgreSQL aborts a transaction with SQLSTATE 40P01. We can catch that exception and retry with exponential backoff.

Java

@Component
@RequiredArgsConstructor
public class DeadlockRetryTemplate {
    private final OrderService orderService;

    public void executeWithRetry(Long orderId, OrderDto dto) {
        int attempts = 0;
        while (true) {
            try {
                orderService.updateOrder(orderId, dto);
                break; // success
            } catch (DataAccessException ex) {
                if (ex.getRootCause() instanceof PSQLException psql &&
                    "40P01".equals(psql.getSQLState())) {
                    attempts++;
                    if (attempts > 5) throw ex;
                    try {
                        Thread.sleep((long) (100 * Math.pow(2, attempts)));
                    } catch (InterruptedException ignored) {}
                } else {
                    throw ex;
                }
            }
        }
    }
}

Spring’s @Retryable can also do this, but a tiny template makes the mechanism explicit.

4. Optimize indexes#

Run EXPLAIN to ensure queries like WHERE id = ? hit the primary‑key index (pk_orders). Missing indexes force PostgreSQL to lock whole tables, which is a deadlock recipe. Add composite indexes if you filter on multiple columns.

5. Avoid SERIALIZABLE unless absolutely needed#

The default READ COMMITTED isolation is sufficient for most workloads. Only switch to SERIALIZABLE when you truly need to prevent phantom reads.

Golden rules#

Lock in a fixed order – always touch dependent tables in the same sequence.
Make transactions as short as possible – include only the operations that truly belong together.
Ensure every WHERE clause has a suitable index.
Retry deadlocks – catch SQLState 40P01 and retry with backoff.
Monitor – enable deadlock logging and regularly query pg_stat_activity.

Key takeaways#

A deadlock is a circular wait for locks; typical culprits are inconsistent lock order, large transactions, unnecessary FOR UPDATE, missing indexes, and high isolation levels.
Fixes: enforce a consistent lock order, shrink transaction scope, add proper indexes, and implement a retry‑with‑backoff strategy.
In Spring Boot, use SELECT … FOR UPDATE, mark read‑only transactions, and wrap write operations in a tiny retry template.

Have you ever run into a deadlock? Share your story and solution in the comments!

Giải quyết deadlock PostgreSQL: 5 nguyên nhân và cách phòng tránhPostgreSQL deadlocks: 5 common causes and how to prevent them

Khi nào deadlock xuất hiện?#

5 lỗi thường gây deadlock trong PostgreSQL#

Giải quyết deadlock PostgreSQL: 5 nguyên nhân và cách phòng tránhPostgreSQL deadlocks: 5 common causes and how to prevent them

Khi nào deadlock xuất hiện?#

5 lỗi thường gây deadlock trong PostgreSQL#

Cách phát hiện nhanh#

Giải pháp thực tiễn cho Spring Boot 3 + Java 21#

1. Đảm bảo thứ tự truy cập thống nhất#

2. Giảm phạm vi transaction#

3. Retry khi deadlock xảy ra#

4. Tối ưu chỉ mục#

5. Tránh mức cô lập SERIALIZABLE nếu không cần#

Quy tắc vàng#

Tóm tắt#

When does a deadlock happen?#

5 common causes of deadlocks in PostgreSQL#

Quick ways to spot a deadlock#

Practical fixes for Spring Boot 3 + Java 21#

1. Enforce a consistent lock ordering#

2. Keep transactions short#

3. Retry on deadlock#

4. Optimize indexes#

5. Avoid SERIALIZABLE unless absolutely needed#

Golden rules#

Key takeaways#

Thảo luậnDiscussion

Khi nào deadlock xuất hiện?#

5 lỗi thường gây deadlock trong PostgreSQL#

Khi nào deadlock xuất hiện?#

5 lỗi thường gây deadlock trong PostgreSQL#

Cách phát hiện nhanh#

Giải pháp thực tiễn cho Spring Boot 3 + Java 21#

1. Đảm bảo thứ tự truy cập thống nhất#

2. Giảm phạm vi transaction#

3. Retry khi deadlock xảy ra#

4. Tối ưu chỉ mục#

5. Tránh mức cô lập SERIALIZABLE nếu không cần#

Quy tắc vàng#

Tóm tắt#

When does a deadlock happen?#

5 common causes of deadlocks in PostgreSQL#

Quick ways to spot a deadlock#

Practical fixes for Spring Boot 3 + Java 21#

1. Enforce a consistent lock ordering#

2. Keep transactions short#

3. Retry on deadlock#

4. Optimize indexes#

5. Avoid SERIALIZABLE unless absolutely needed#

Golden rules#

Key takeaways#

Bài học liên quanRelated lessons

Retry with Exponential Backoff

Thảo luậnDiscussion

Practical fixes for Spring Boot 3 + Java 21#