Spring Data JPA唯一约束校验：多线程并发保存问题咨询

Great question! Let's break this down step by step:

• First, you're dealing with a classic race condition: when 10 threads run isUnique() at nearly the same time, all will get true because none have actually persisted the entity yet.
• When these threads move on to save the product, the first one to reach the database will successfully insert the record. Every subsequent thread will trigger the database's unique constraint, which will throw an exception (like SQLIntegrityConstraintViolationException, depending on your database and JDBC driver). This is unavoidable because the isUnique() check and save() operation aren't atomic—there's a small window between the check and save where another thread can slip in and create the record first.

Database-level unique constraints are your last line of defense, but relying on them to throw exceptions isn't ideal (it's inefficient and messy to handle). Here are practical, actionable solutions:

1. Synchronize the critical section in the application layer

   • For a single app instance, use a synchronized block, but lock on a key tied to the product's unique field (e.g., its SKU) instead of the entire service class—this avoids unnecessary performance bottlenecks. Example:

     public void save(Product p) {
         String uniqueSku = p.getSku();
         // Use intern() to ensure identical SKUs share the same string instance for locking
         synchronized (uniqueSku.intern()) {
             if (isUnique(p)) {
                 repository.save(p);
             }
         }
     }
     

   • For distributed systems (multiple app instances), use a distributed lock (e.g., with Redis or ZooKeeper) where the lock key is the product's unique field. This ensures only one thread across all instances can run the check-and-save sequence for a given product.

2. Use atomic database operations

   • Skip the pre-save check entirely and let the database handle the uniqueness check and insert in one atomic step. For example:
     • MySQL: INSERT INTO products (...) VALUES (...) ON DUPLICATE KEY UPDATE ... (if your logic allows updating existing records instead of failing)
     • PostgreSQL: INSERT INTO products (...) VALUES (...) ON CONFLICT (unique_column) DO NOTHING or DO UPDATE
   • This eliminates the race condition completely because the database executes the operation as a single, unbreakable unit.

3. Catch the constraint exception and retry

   • If you can't modify the save logic to use atomic database commands, catch the unique constraint exception, re-run isUnique(), and skip saving if it now returns false. Be sure to limit retry counts to avoid infinite loops, and handle transaction rollbacks properly.

4. Pessimistic locking? (Not ideal for insert scenarios)

   • Pessimistic locks (like SELECT ... FOR UPDATE) work well for updating existing records, but they don't help here—since the product row doesn't exist yet, there's nothing to lock.

Never remove the database-level unique constraint! It's your safety net for when application-level locks fail (e.g., bugs in distributed lock logic, direct database changes from other systems). Combining it with application-level atomic checks or database atomic operations will keep your code clean and avoid unnecessary exceptions.

内容的提问来源于stack exchange，提问作者minizibi