在经历了一些问题之后，我想我已经明白为什么我走错了。

我写了一个数据库包装类，其中包括一个close()，它调用helper close作为open()的镜像，它调用getWriteableDatabase，然后迁移到ContentProvider。ContentProvider的模型不使用sqlitedatdatabase .close()，我认为这是一个很大的线索，因为代码确实使用了getWriteableDatabase在某些情况下，我仍然在做直接访问(屏幕验证查询，所以我迁移到一个getWriteableDatabase/rawQuery模型。

我使用了一个单例，在关闭的文档中有一些不祥的注释

关闭任何打开的数据库对象

(我的粗体)。

因此，当我使用后台线程访问数据库时，它们与前台同时运行，就会出现间歇性崩溃。

因此，我认为close()强制数据库关闭，而不管是否有其他线程持有引用——因此close()本身不是简单地撤销匹配的getWriteableDatabase，而是强制关闭任何打开的请求。大多数情况下，这不是问题，因为代码是单线程的，但在多线程的情况下，总是有机会打开和关闭不同步。

Having read comments elsewhere that explains that the SqLiteDatabaseHelper code instance counts, then the only time you want a close is where you want the situation where you want to do a backup copy, and you want to force all connections to be closed and force SqLite to write away any cached stuff that might be loitering about - in other words stop all application database activity, close just in case the Helper has lost track, do any file level activity (backup/restore) then start all over again.

虽然这听起来像一个好主意，尝试和关闭在受控的方式，现实是Android保留垃圾你的虚拟机的权利，所以任何关闭都是减少缓存更新不被写入的风险，但不能保证如果设备是有压力的，如果你已经正确释放游标和数据库引用(不应该是静态成员)，那么助手将关闭数据库无论如何。

所以我的看法是:

使用getWriteableDatabase从单例包装器打开。(我使用了一个派生的应用程序类来提供应用程序上下文，从而解决了对上下文的需求)。

永远不要直接接近。

永远不要将结果数据库存储在任何没有明显作用域并依赖引用计数来触发隐式close()的对象中。

如果进行文件级处理，请暂停所有数据库活动，然后调用close，以防出现失控线程，假设您编写了适当的事务，那么失控线程将失败，关闭的数据库至少将拥有适当的事务，而不是部分事务的文件级副本。

在经历了一些问题之后，我想我已经明白为什么我走错了。

我写了一个数据库包装类，其中包括一个close()，它调用helper close作为open()的镜像，它调用getWriteableDatabase，然后迁移到ContentProvider。ContentProvider的模型不使用sqlitedatdatabase .close()，我认为这是一个很大的线索，因为代码确实使用了getWriteableDatabase在某些情况下，我仍然在做直接访问(屏幕验证查询，所以我迁移到一个getWriteableDatabase/rawQuery模型。

我使用了一个单例，在关闭的文档中有一些不祥的注释

关闭任何打开的数据库对象

(我的粗体)。

因此，当我使用后台线程访问数据库时，它们与前台同时运行，就会出现间歇性崩溃。

因此，我认为close()强制数据库关闭，而不管是否有其他线程持有引用——因此close()本身不是简单地撤销匹配的getWriteableDatabase，而是强制关闭任何打开的请求。大多数情况下，这不是问题，因为代码是单线程的，但在多线程的情况下，总是有机会打开和关闭不同步。

Having read comments elsewhere that explains that the SqLiteDatabaseHelper code instance counts, then the only time you want a close is where you want the situation where you want to do a backup copy, and you want to force all connections to be closed and force SqLite to write away any cached stuff that might be loitering about - in other words stop all application database activity, close just in case the Helper has lost track, do any file level activity (backup/restore) then start all over again.

虽然这听起来像一个好主意，尝试和关闭在受控的方式，现实是Android保留垃圾你的虚拟机的权利，所以任何关闭都是减少缓存更新不被写入的风险，但不能保证如果设备是有压力的，如果你已经正确释放游标和数据库引用(不应该是静态成员)，那么助手将关闭数据库无论如何。

所以我的看法是:

使用getWriteableDatabase从单例包装器打开。(我使用了一个派生的应用程序类来提供应用程序上下文，从而解决了对上下文的需求)。

永远不要直接接近。

永远不要将结果数据库存储在任何没有明显作用域并依赖引用计数来触发隐式close()的对象中。

如果进行文件级处理，请暂停所有数据库活动，然后调用close，以防出现失控线程，假设您编写了适当的事务，那么失控线程将失败，关闭的数据库至少将拥有适当的事务，而不是部分事务的文件级副本。

德米特罗的回答很适合我。 我认为最好将函数声明为同步的。至少在我的情况下，它会调用空指针异常，否则，例如getWritableDatabase尚未返回在一个线程和opendatabase在另一个线程同时调用。

public synchronized SQLiteDatabase openDatabase() {
    if(mOpenCounter.incrementAndGet() == 1) {
        // Opening new database
        mDatabase = mDatabaseHelper.getWritableDatabase();
    }
    return mDatabase;
}

并发数据库访问

同样的文章在我的博客上(我更喜欢格式化)

我写了一篇小文章，描述了如何让访问你的android数据库线程安全。

---

假设你有自己的SQLiteOpenHelper。

public class DatabaseHelper extends SQLiteOpenHelper { ... }

现在，您希望在不同的线程中将数据写入数据库。

 // Thread 1
 Context context = getApplicationContext();
 DatabaseHelper helper = new DatabaseHelper(context);
 SQLiteDatabase database = helper.getWritableDatabase();
 database.insert(…);
 database.close();

 // Thread 2
 Context context = getApplicationContext();
 DatabaseHelper helper = new DatabaseHelper(context);
 SQLiteDatabase database = helper.getWritableDatabase();
 database.insert(…);
 database.close();

您将在日志中得到以下消息，并且您的一个更改将不会被写入。

android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5)

这是因为每次创建新的SQLiteOpenHelper对象时，实际上都在建立新的数据库连接。如果您试图同时从不同的实际连接写入数据库，其中一个将失败。(从上面的答案)

要使用多线程数据库，我们需要确保我们使用的是一个数据库连接。

让我们创建一个单例类Database Manager，它将保存并返回一个SQLiteOpenHelper对象。

public class DatabaseManager {

    private static DatabaseManager instance;
    private static SQLiteOpenHelper mDatabaseHelper;

    public static synchronized void initializeInstance(SQLiteOpenHelper helper) {
        if (instance == null) {
            instance = new DatabaseManager();
            mDatabaseHelper = helper;
        }
    }

    public static synchronized DatabaseManager getInstance() {
        if (instance == null) {
            throw new IllegalStateException(DatabaseManager.class.getSimpleName() +
                    " is not initialized, call initialize(..) method first.");
        }

        return instance;
    }

    public SQLiteDatabase getDatabase() {
        return new mDatabaseHelper.getWritableDatabase();
    }

}

在不同的线程中向数据库写入数据的更新代码如下所示。

 // In your application class
 DatabaseManager.initializeInstance(new MySQLiteOpenHelper());
 // Thread 1
 DatabaseManager manager = DatabaseManager.getInstance();
 SQLiteDatabase database = manager.getDatabase()
 database.insert(…);
 database.close();

 // Thread 2
 DatabaseManager manager = DatabaseManager.getInstance();
 SQLiteDatabase database = manager.getDatabase()
 database.insert(…);
 database.close();

这将给你带来另一次崩溃。

java.lang.IllegalStateException: attempt to re-open an already-closed object: SQLiteDatabase

由于我们只使用一个数据库连接，getDatabase()方法为Thread1和Thread2返回相同的SQLiteDatabase对象实例。发生了什么，Thread1可能会关闭数据库，而Thread2仍在使用它。这就是为什么我们有IllegalStateException崩溃。

我们需要确保没有人在使用数据库，然后才关闭它。stackoverflow上的一些人建议永远不要关闭你的SQLiteDatabase。这将导致以下logcat消息。

Leak found
Caused by: java.lang.IllegalStateException: SQLiteDatabase created and never closed

工作样本

public class DatabaseManager {

    private int mOpenCounter;

    private static DatabaseManager instance;
    private static SQLiteOpenHelper mDatabaseHelper;
    private SQLiteDatabase mDatabase;

    public static synchronized void initializeInstance(SQLiteOpenHelper helper) {
        if (instance == null) {
            instance = new DatabaseManager();
            mDatabaseHelper = helper;
        }
    }

    public static synchronized DatabaseManager getInstance() {
        if (instance == null) {
            throw new IllegalStateException(DatabaseManager.class.getSimpleName() +
                    " is not initialized, call initializeInstance(..) method first.");
        }

        return instance;
    }

    public synchronized SQLiteDatabase openDatabase() {
        mOpenCounter++;
        if(mOpenCounter == 1) {
            // Opening new database
            mDatabase = mDatabaseHelper.getWritableDatabase();
        }
        return mDatabase;
    }

    public synchronized void closeDatabase() {
        mOpenCounter--;
        if(mOpenCounter == 0) {
            // Closing database
            mDatabase.close();

        }
    }

}

如下所示。

SQLiteDatabase database = DatabaseManager.getInstance().openDatabase();
database.insert(...);
// database.close(); Don't close it directly!
DatabaseManager.getInstance().closeDatabase(); // correct way

每次你需要数据库时，你应该调用DatabaseManager类的openDatabase()方法。在这个方法中，我们有一个计数器，指示数据库被打开的次数。如果它等于1，这意味着我们需要创建新的数据库连接，如果不等于1，则数据库连接已经创建。

同样的情况也发生在closeDatabase()方法中。每次调用此方法时，计数器都会减小，当它趋于0时，我们将关闭数据库连接。

---

现在您应该能够使用数据库并确保它是线程安全的。

我知道响应晚了，但在android中执行sqlite查询的最佳方式是通过自定义内容提供程序。这样，UI就与数据库类(扩展SQLiteOpenHelper类的类)解耦了。此外，查询在后台线程(游标加载器)中执行。

数据库在多线程方面非常灵活。我的应用程序从许多不同的线程同时击中它们的db，它做得很好。在某些情况下，我有多个进程同时访问数据库，这也很好。

你的异步任务-当你可以使用相同的连接，但如果你必须，它可以从不同的任务访问数据库。