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

在纠结了几个小时之后，我发现每次db执行只能使用一个db helper对象。例如,

for(int x = 0; x < someMaxValue; x++)
{
    db = new DBAdapter(this);
    try
    {

        db.addRow
        (
                NamesStringArray[i].toString(), 
                StartTimeStringArray[i].toString(),
                EndTimeStringArray[i].toString()
        );

    }
    catch (Exception e)
    {
        Log.e("Add Error", e.toString());
        e.printStackTrace();
    }
    db.close();
}

相对于:

db = new DBAdapter(this);
for(int x = 0; x < someMaxValue; x++)
{

    try
    {
        // ask the database manager to add a row given the two strings
        db.addRow
        (
                NamesStringArray[i].toString(), 
                StartTimeStringArray[i].toString(),
                EndTimeStringArray[i].toString()
        );

    }
    catch (Exception e)
    {
        Log.e("Add Error", e.toString());
        e.printStackTrace();
    }

}
db.close();

每次循环迭代时创建一个新的DBAdapter是我通过助手类将字符串放入数据库的唯一方法。

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

我写了一个数据库包装类，其中包括一个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，以防出现失控线程，假设您编写了适当的事务，那么失控线程将失败，关闭的数据库至少将拥有适当的事务，而不是部分事务的文件级副本。

在多线程中插入、更新、删除和读取通常是可以的，但是Brad的答案是不正确的。你必须小心如何创建和使用你的联系。在某些情况下，即使数据库没有损坏，更新调用也会失败。

最基本的答案。

SqliteOpenHelper对象保留一个数据库连接。它看似为您提供了读写连接，但实际上并非如此。调用read-only，无论如何都将获得写数据库连接。

一个helper实例，一个db连接。即使您在多个线程中使用它，也只能一次使用一个连接。SqliteDatabase对象使用java锁来保持访问序列化。因此，如果100个线程拥有一个db实例，则对实际磁盘上数据库的调用将被序列化。

一个helper，一个db连接，在java代码中序列化。一个线程，1000个线程，如果你使用一个helper实例在它们之间共享，你所有的db访问代码都是串行的。生活是美好的。

如果您试图同时从不同的实际连接写入数据库，其中一个将失败。它不会等到第一个完成后再写。它将不编写您的更改。更糟糕的是，如果您没有在SQLiteDatabase上调用正确的insert/update版本，则不会出现异常。您只会在LogCat中收到一条消息，仅此而已。

多线程?使用一个帮手。时期。如果你知道只有一个线程在写，你可以使用多个连接，你的读取速度会更快，但买家要小心。我还没测试那么多。

这里有一篇博客文章提供了更多的细节和一个示例应用程序。

Android Sqlite锁定(更新链接6/18/2012) android - database - lock - collisions - example by touchlab on GitHub

Gray和我实际上正在包装一个ORM工具，基于他的Ormlite，它与Android数据库实现原生工作，并遵循我在博客文章中描述的安全创建/调用结构。应该很快就能出来了。来看看。

与此同时，还有一篇后续博文:

单个SQLite连接

同样签出前面提到的锁定示例的2point0的fork:

Android-Database-Locking-Collisions-Example by 2point0 on GitHub

您可以尝试应用谷歌I/O 2017上宣布的新架构方法。

它还包括新的ORM库Room

它包含三个主要组件:@Entity， @Dao和@Database

User.java

@Entity
public class User {
  @PrimaryKey
  private int uid;

  @ColumnInfo(name = "first_name")
  private String firstName;

  @ColumnInfo(name = "last_name")
  private String lastName;

  // Getters and setters are ignored for brevity,
  // but they're required for Room to work.
}

UserDao.java

@Dao
public interface UserDao {
  @Query("SELECT * FROM user")
  List<User> getAll();

  @Query("SELECT * FROM user WHERE uid IN (:userIds)")
  List<User> loadAllByIds(int[] userIds);

  @Query("SELECT * FROM user WHERE first_name LIKE :first AND "
       + "last_name LIKE :last LIMIT 1")
  User findByName(String first, String last);

  @Insert
  void insertAll(User... users);

  @Delete
  void delete(User user);
}

AppDatabase.java

@Database(entities = {User.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
  public abstract UserDao userDao();
}

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

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