Java多线程场景下如何安全且高效地执行数据库编辑操作

你当前遇到的性能瓶颈核心是JVM层面全局synchronized锁的粒度过粗，直接把并行插入强制转为串行，且完全没有利用数据库本身的并发控制能力，可从以下几个方向优化，全程保障数据安全：

• 移除JVM层全局同步锁，改用数据库原生能力保障正确性
  synchronized属于JVM进程内锁，本身就不适合作为数据库操作的并发控制手段：如果后续部署多实例集群，这个锁会直接失效，完全起不到安全控制作用。普通插入场景下，只要不存在多线程修改同一条数据、重复插入唯一键等业务冲突，数据库默认的事务隔离级别（比如常用的读已提交RC级别）就可以保障数据写入的正确性，不需要额外叠加JVM层的全局锁，100个线程可以并行向数据库发起插入请求，性能会有数量级提升。
• 改用批量插入降低网络和IO开销
  单条插入的网络往返、数据库事务提交开销极高，你可以用BlockingQueue缓存多个线程的插入请求，专门启动少量消费线程将多条插入数据合并为批量SQL执行，语法为insert into 表名 (字段1,字段2) values (值1,值2),(值3,值4)...，单次提交几十到上百条数据，可将整体写入效率提升5~10倍。
• 分段锁缩小锁粒度（适用于需要业务并发控制的场景）
  如果业务层面确实需要做并发控制（比如要避免同个业务ID的重复插入），不要锁整个方法，改用分段锁机制：按业务ID哈希取模拆分出N个独立锁，只有哈希值相同的请求才会竞争同一把锁，不同分段的请求可以完全并行执行，并发能力会随分段数线性提升。
• 合理控制并发线程数，搭配数据库连接池使用
  数据库的并发写入承载能力有上限，普通单机MySQL的最佳并发写线程数在16~32之间，100个线程同时发起写入反而会导致大量线程上下文切换、数据库连接竞争的额外开销。你可以将插入线程数调整到和数据库连接池最大连接数匹配，避免无效调度开销。
• 异步削峰适配数据库写入能力
  如果业务对插入实时性要求不高，可以将插入请求先写入本地内存队列或MQ中间件，只要消息写入成功就返回业务结果，后台用固定数量的消费线程批量消费写入数据库，既不会阻塞业务主线程，也能将数据库写入速度控制在承载范围内，起到削峰填谷的作用。

补充说明：如果插入存在唯一键冲突的场景，可以直接使用数据库的INSERT ... ON DUPLICATE KEY UPDATE语法处理冲突，不需要额外加锁做前置判断，进一步提升效率。

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