是否有greenDAO线程安全最佳实践？

Question

我正在使用greenDAO,到目前为止一切都很顺利.文档或网站(或任何地方:()似乎没有涉及的一件事是它如何处理线程安全.

我知道其他地方提到的基础知识,比如"使用单个dao会话"(Android + SQLite的一般做法),我非常了解Java内存模型.库内部甚至看起来是线程安全的,或者至少是用这种意图构建的.但我见过的一切都没有涵盖这个:

greenDAO默认缓存实体. 这对于完全单线程程序来说非常好 - 透明和大多数用途的大量性能提升.但是,如果我loadAll()然后修改其中一个元素,我将在我的应用程序中全局修改同一个对象.如果我在主线程上使用它(例如用于显示),并在后台线程上更新数据库(正确和正确),除非特别小心,否则会出现明显的线程问题.

greenDAO是否在"引擎盖下"做任何事情以防止常见的应用程序级线程问题？例如,修改UI线程中的缓存实体,同时将其保存在后台线程中(更好的希望它们不会交错!特别是在修改列表时!)？是否有任何"最佳实践"来防范它们,超出了一般的线程安全问题(即greenDAO期望和适用的东西)？或者从多线程应用程序的安全角度看整个缓存是否存在致命缺陷？

Answer 1

我没有使用 greenDAO 的经验，但这里有文档：\n http://greendao-orm.com/documentation/queries/

\n

说：

\n

\n

如果在多个线程中使用查询，则必须在查询上调用 forCurrentThread() 来获取当前线程的 Query 实例。从 greenDAO 1.3 开始，Query 的对象实例绑定到它们自己的构建查询的线程。这使您可以安全地设置查询对象的参数，而其他线程无法干扰。如果其他线程尝试在查询上设置参数或执行绑定到另一个线程的查询，则会抛出异常。像这样，您不需要\xe2\x80\x99t 同步语句。事实上，您应该避免锁定，因为如果并发事务使用相同的 Query 对象，这可能会导致死锁。

\n

为了完全避免这些潜在的死锁，greenDAO 1.3 引入了 forCurrentThread() 方法。这将返回查询的线程本地实例，该实例可以在当前线程中安全使用。每次调用 forCurrentThread() 时，参数都会设置为使用其构建器构建查询时的初始参数。

\n

\n

虽然据我所知，文档没有明确说明除此之外的任何有关多线程的内容，但这似乎很清楚它已得到处理。这里讨论的是多个线程使用同一个 Query 对象，因此显然多个线程可以访问同一个数据库。当然，数据库和 DAO 处理并发访问是正常的，并且有许多经过验证的技术可以在这种情况下使用缓存。

\n