Является ли потокобезопасным SQLite?

Является ли SQLite потокобезопасным?

Прямой ответ: да, SQLite может быть потокобезопасным, но по умолчанию — нет. Его поведение зависит от выбранного режима компиляции и корректного использования API в многопоточной среде. В iOS-разработке это особенно важно, так как приложения часто используют несколько потоков (например, главный поток UI и фоновые потоки для операций с базой данных).

Режимы потокобезопасности SQLite

SQLite предоставляет три режима потокобезопасности, которые определяются на этапе компиляции библиотеки:

1. SQLITE_THREADSAFE=0 (Single-threaded): Полностью не потокобезопасен. Все функции SQLite должны вызываться из одного потока. Этот режим запрещён в iOS, так как система сама использует многопоточность.
2. SQLITE_THREADSAFE=1 (Serialized): Режим по умолчанию в большинстве сборок, включая iOS. Потокобезопасен: SQLite автоматически использует мьютексы для защиты внутренних структур данных. Несколько потоков могут одновременно использовать разные соединения с базой данных, но каждое соединение должно быть изолировано.
3. SQLITE_THREADSAFE=2 (Multi-threaded): Ограниченная потокобезопасность. Отдельные соединения можно использовать в разных потоках, но нельзя передавать одно соединение между потоками без синхронизации.

В iOS стандартная сборка SQLite использует режим Serialized (SQLITE_THREADSAFE=1), что обеспечивает базовую потокобезопасность. Узнать текущий режим можно через вызов sqlite3_threadsafe().

Практические ограничения и рекомендации для iOS

Несмотря на режим Serialized, разделение одного соединения SQLite между потоками без синхронизации приводит к сбоям. Основное правило: одно соединение (sqlite3*) должно использоваться только в одном потоке в конкретный момент времени. Для многопоточного доступа есть несколько подходов:

1. Использование отдельных соединений для каждого потока:

   // Поток 1
   sqlite3 *db1;
   sqlite3_open("database.db", &db1);
   // Работа с db1 только в потоке 1
   
   // Поток 2
   sqlite3 *db2;
   sqlite3_open("database.db", &db2); // Отдельное соединение
   // Работа с db2 только в потоке 2
   

2. Глобальная блокировка доступа к соединению (например, через @synchronized в Objective-C или DispatchQueue в Swift):

   let databaseQueue = DispatchQueue(label: "com.example.database")
   var db: OpaquePointer?
   
   databaseQueue.sync {
       // Все операции с db выполняются на этой очереди
       sqlite3_exec(db, "INSERT INTO logs (message) VALUES ('test')", nil, nil, nil)
   }
   

3. Использование WAL (Write-Ahead Logging) режима — в iOS он включён по умолчанию с SQLite 3.7.16+. WAL позволяет читать и записывать параллельно, повышая производительность:

   PRAGMA journal_mode=WAL; -- Активация WAL (обычно установлен по умолчанию в iOS)
   

Распространённые ошибки в iOS-разработке

• Передача подготовленных выражений (sqlite3_stmt*) между потоками — это небезопасно, даже если соединение защищено. Каждый поток должен готовить свои выражения.
• Игнорирование транзакций при одновременных запросах на запись, что может приводить к deadlock или повреждению данных. Обязательно используйте BEGIN TRANSACTION и COMMIT.
• Неиспользование FMDatabaseQueue (для Objective-C) или GRDB (для Swift) — эти библиотеки предоставляют удобные абстракции для потокобезопасной работы. Например, в GRDB:

  let dbQueue = DatabaseQueue(path: "database.db")
  try dbQueue.write { db in
      try db.execute(sql: "INSERT INTO users (name) VALUES (?)", arguments: ["Alice"])
  }
  

Итог для iOS-разработчика

SQLite в iOS потокобезопасен в режиме Serialized, но разработчик обязан:

1. Изолировать соединения по потокам или использовать очереди.
2. Предпочитать отдельные соединения или высокоуровневые обёртки (Core Data, GRDB, SQLite.swift).
3. Активировать WAL и корректно работать с транзакциями.

Таким образом, потокобезопасность SQLite — не автоматическая гарантия, а результат правильной архитектуры доступа к данным в приложении.