java - 锁定性能 : Lock Longer vs. 更频繁地锁定

Question

快速背景:当我回过头来重新设计应用程序的一些关键部分时，我一直想知道锁定及其对性能的影响。该应用程序具有大型树形数据结构，可缓存数据库中的数据/DTO。对大树的更新可以通过两种主要方式进行:1. 用户触发的命令，2. 从后台运行的作业自动更新。

当任一操作类型发生(用户/自动)时，我都会锁定(显式锁定)数据结构。我遇到了一致性问题，因此锁定所有内容似乎对于保护缓存中数据的完整性最有意义。

问题:由于许多自动更新可以同时发生，我正在考虑实现某种队列(可能是 JMS)来处理数据结构的指令，其中任何用户驱动的更新都被推送到顶部并首先处理。当涉及到处理大量/未知大小的自动“任务”时，我试图弄清楚是否应该让它们单独运行和锁定，或者尝试按时间将它们批量组合在一起并与锁定交互一次。问题的真正症结在于，任何一个要更新的任务都可能影响整个树。

就整体性能而言(一般，没有什么具体的)，让许多事务锁定可能进行大型更新，或者尝试合并到一个大规模批量更新并且只锁定一次但锁定时间更长，是否更有效？我知道这在很大程度上可能取决于数据、更新类型、频率等。我不知道是否存在“更小更频繁的锁”或“一个可能更长的大锁”的一般经验法则。

Answer 1

我认为答案取决于您的程序是否花费大量时间来解锁数据结构。如果没有，我建议对所有待处理的更新锁定一次。

原因是，当更新线程快速再次锁定资源时，可能正在等待锁定的其他线程可能会被唤醒，然后无用地返回 sleep 状态。或者更新被另一个线程中断，这可能不利于缓存利用率。此外，锁定的成本与更新相比可能很小:管道可能必须刷新，内存访问可能无法自由地重新排序，等等。

如果线程在更新之间花费一些时间而无需锁定数据结构，并且预计其他线程可以在其间完成其事务，从而减少争用，那么我会考虑为每次更新重新锁定。

请注意，当不同的更新有不同的优先级时，就像我假设您的用户更新与后台更新一样，长时间锁定数据结构以进行较低优先级的更新可能不是一个好主意(如果可以的话)阻止更高优先级任务运行的方法。