做客户端开发这些年“数据写到一半挂了”这种情况碰到的次数真不算少。尤其是一直在用LitePal这种轻量级ORM框架的前期CRUD写起来确实爽但真到了批量导入、多表联动这种需要“要么全成、要么全败”的场景少了官方的事务支持总感觉像在走钢丝。最近LitePal更新补上了事务能力这消息对我们这些重度用户来说算是一块石头落了地。这篇不是官方文档的翻译我更想从一个实际做项目的人的角度把事务这件事从头到尾捋一遍为什么需要事务、LitePal的事务到底怎么用、底层发生了什么、有哪些必须躲开的坑。不管你是刚开始用LitePal的新手还是已经把它跑在线上项目里的老手这篇文章应该都能给你一些参考。1. 为什么需要事务从一个真实场景说起先讲一个让我印象深刻的线上事故。某个产品有个“收藏合集”的功能用户点一下按钮客户端要往本地数据库里批量写入二十几篇文章的记录还要同步更新收藏夹的时间戳。本来逻辑不复杂但就是有用户反馈收藏了几篇之后下次打开App收藏夹里只有一半文章而且看不到任何报错。排查下来不是代码逻辑写错了而是“原子性”缺失。批量写二十几篇文章写到第十篇的时候进程被系统回收了数据库里已经存在的十篇文章就留了下来后面的十篇根本没机会执行整个收藏夹的数据就成了残缺状态。如果能有一个机制让这二十几条写入操作绑在一起要么全部提交生效要么全部撤销就不会出现这种半截数据的情况。这就是数据库事务存在的意义。事务有四个被反复提到的特性原子性、一致性、隔离性、持久性但日常开发里真正要盯住的其实是最前面的原子性。所谓原子性就是指一个事务里的所有操作被视为一个不可分割的整体任何一步失败全部落库修改都会被撤销像是从来没发生过一样。一致性说的是事务执行前后数据必须满足所有预设的约束规则比如外键关系、唯一索引都不能被破坏。隔离性解决的是多个事务并发执行时互不干扰的问题这个在服务端数据库里是重头戏在单机SQLite里也有体现但没有那么复杂。持久性很好理解事务一旦提交成功修改就会永久保存不会因为App退出或断电而丢失。在LitePal还没有事务支持的时候很多项目组处理这类问题的方式千奇百怪有人自己拿SQLiteDatabase写try/catch有人干脆不做任何保护还有人自己封装一套异常补偿逻辑复杂到后面没人敢碰。LitePal跟进的这个事务特性其实就是把那些散落在各处的民间写法收敛到了官方API层面让业务代码不用再纠结那些底层的繁琐细节。2. LitePal事务支持的两种用法照着抄就行2.1 最直接的写法拿到底层数据库对象再开事务LitePal封装得很轻所以它从没有把SQLiteDatabase完全藏起来。最直白也最兼容的做法就是通过LitePal.getDatabase()拿到数据库对象然后使用Android SDK自带的SQLiteDatabase事务API。SQLiteDatabase db LitePal.getDatabase(); db.beginTransaction(); try { // 在这里写你的数据库操作代码 db.setTransactionSuccessful(); } catch (Exception e) { // 异常时走到这里事务会在endTransaction时回滚 Log.e(TAG, 事务执行失败, e); } finally { db.endTransaction(); }这个写法看着简单里面有三件容易被忽略的事。第一beginTransaction()和endTransaction()必须成对出现而且endTransaction()要放在finally块里保证无论中间代码是否抛异常它都能被执行。如果漏掉了endTransaction()数据库会一直停留在事务状态后续其他线程的写操作会排队阻塞严重时整张表都写不进去数据。第二setTransactionSuccessful()必须在所有数据库操作完成之后调用而且调用完这行的代码之后不应该再有任何数据库写操作。它在底层相当于给事务打了一个“可以提交”的标记只有带了这个标记endTransaction()才会执行COMMIT否则直接执行ROLLBACK把一切都撤销。第三如果你在事务里同时使用了LitePal的Model方法比如save()、delete()和原生SQL操作只要它们都走同一个数据库实例就会被同一个事务管理。我自己常用的场景是循环article.save()批量落库外层包一个事务非常简单。2.2 LitePal封装的简洁事务入口新版本里LitePal提供了更简洁的静态事务方法代码可以写得跟SDK原生API几乎一模一样只不过入口变成了LitePal类。LitePal.beginTransaction(); try { articleList.forEach { it.save() } LitePal.setTransactionSuccessful(); } catch (Exception e) { Log.e(TAG, batch save failed, e); } finally { LitePal.endTransaction(); }这段是Kotlin的写法Java版本的逻辑完全一样只是把forEach换成普通的for循环。如果你项目里的LitePal版本暂时找不到这几个静态方法直接退回2.1里那种getDatabase()的写法就可以两者在事务语义上是同一套机制不用纠结。有一点要提醒LitePal.beginTransaction()这几个方法名看起来跟Android SDK的一致但内部实现可能会针对LitePal的连接管理做一些封装。所以升级LitePal版本后如果你的项目里有多处事务代码最好做一轮回归测试确认事务内的数据操作都能正常提交和回滚。轻量级框架升级带来的细微行为变化往往就藏在没人注意的边界场景里。2.3 嵌套事务的坑能躲就躲嵌套事务是一个老生常谈又极其容易踩坑的话题。举个例子你的批量收藏方法里调用了另一个封装好的数据操作方法而那个方法内部自己也开了事务两层事务叠加在一起结果往往不是你想象的那样。SQLiteDatabase的事务在Android里虽然支持嵌套调用但这种“支持”不代表语义跟单层事务一样直观。内层事务的提交标志和外层事务的提交标志会互相影响一旦内层抛了异常回滚了外层可能也会被牵连。更麻烦的是如果两层都调用了setTransactionSuccessful()但最外层最终回滚整个数据状态就会变得非常难排查。我的经验是在团队协作里直接立一条规矩只允许最外层的业务入口开启事务任何被封装的公共数据操作方法都禁止自己调beginTransaction()。如果确实需要内层逻辑在特定情况下独立回滚应该通过参数或者返回值让外层来决定整体是提交还是回滚而不是各自开事务。3. 事务内部的执行流程与源码级原理解读用多了就会好奇这几行API背后数据库到底发生了什么。搞懂这些问题不是为了写博客炫耀而是为了在出问题时能快速定位是逻辑锅还是API锅。3.1 从beginTransaction到endTransaction发生了什么当调用beginTransaction()时底层对应的是SQLite的BEGIN IMMEDIATE操作。从这一刻开始后续所有写操作都不会立刻真正落盘而是记录在内存页缓存和日志里直到收到明确的COMMIT或ROLLBACK指令。这也是事务能带来性能提升的根本原因数据库不需要在每条SQL之后都做一次完整的磁盘同步而是把大量修改攒在内存里最后一次性同步到磁盘。拿做饭来类比的话独立提交就像每炒一道菜就端出去一趟事务则是一桌子菜全部炒完再一起上桌省掉的是中间来回跑路的次数。setTransactionSuccessful()到endTransaction()之间的间隙决定了事务最终是提交还是回滚。endTransaction()相当于一个裁判检查标记有成功标记就执行COMMIT把事务期间的所有修改永久写入数据库没有标记就执行ROLLBACK把日志里的修改全部撤销数据恢复到这个事务开始之前的状态。3.2 setTransactionSuccessful为什么必须放在finally之前这个问题的答案其实就在名字里。setTransactionSuccessful()的作用是“标记事务成功”它应该是在所有数据库操作都确认无误后、事务即将结束前做的最后一个动作。如果你把数据库操作放在标记之后那标记就没意义了如果你忘了调用标记那么无论操作多么顺利endTransaction()也会认定事务失败并回滚全部改动。这里还有一个更隐蔽的陷阱。如果在调用setTransactionSuccessful()之后、但事务还没有提交之前又发生了异常并执行了某些数据库写操作事务最终的状态在不同Android版本上的表现不一定完全一致。为了杜绝这种不确定性最稳妥的策略非常朴素setTransactionSuccessful()放在try块的最后一行调用完之后任何可能产生数据库写入的代码都不要出现在它后面。只要遵循这个顺序无论底层实现细节怎么变化行为都是可预期的。3.3 事务回滚到底回滚了什么有个容易混淆的点事务回滚只撤销当前数据库连接中的写操作也就是INSERT、UPDATE、DELETE这些DML操作。它不会撤销事务之外的任何东西不会撤销你对内存变量的修改不会撤销SharedPreferences里的写入更不会把已经发出去的网络请求收回来。所以设计事务边界时脑子里要有根弦事务只对自己的数据库修改负责。不要在一个事务里既写数据库又做文件IO又发起网络请求一旦后面的网络请求失败导致事务回滚数据库虽然干净了但文件已经写了、网络消息已经发出去了这时候反而产生另一种不一致。事务的面积应该尽量纯粹只包含需要被原子提交的数据库操作。4. 什么时候该用事务以及性能真相4.1 适合用事务的典型场景最常见的场景就是批量写入。比如消息类App首次同步历史聊天记录从服务器拉下来两三千条消息要插进本地数据库。如果逐条独立提交每一条写入都要触发一次磁盘同步整体耗时慢得肉眼可见。而把所有插入包进一个事务里几千条消息在内存中改完最后一次性落盘速度差距是数量级的。第二种场景是级联写。主表加一条记录同时要给关联表更新几条关联数据比如创建订单要同时写订单明细、更新商品销量、记录操作日志。这些跨表的操作必须作为一个整体成功或整体失败单独拎出任何一条语句提交都是不完整的。第三种场景是先查后改的复合操作。比如更新某个用户资料的显示排名代码里要先统计当前排名然后更新用户表和排名表两个表。查询和写入之间有业务逻辑判断这种复合操作也适合用事务保护避免在统计和写入之间数据被其他线程改动。4.2 不该用事务的场景别把性能想得太神单条记录写入就不要专门开事务了。SQLite本身对每条DML语句都会有隐式的自动提交机制相当于它自己就是一个最小事务。再显式地包一层事务虽然不会出错但也没有任何收益反而多了一层嵌套和状态管理的复杂度。这种属于典型的没事找事。只读查询也不需要事务。查询操作不会改变数据库内容不存在原子性风险。有些同学习惯性地把所有数据库访问都包进事务里其实纯粹是被模板代码带偏了。最需要注意的是长循环内的耗时操作。如果你在一个事务里遍历一千条数据每条数据的处理过程中还穿插着网络请求或者复杂的文件解析这个事务的持续时间会非常长。事务期间数据库的写锁被长期占着其他线程的写入全部会被阻塞操作一多甚至会出现SQLiteBusyException。把事务当成万能加速器是危险的它只适合“快进快出”的批量操作。4.3 关于事务性能的实测感受我自己在真机上做过对比一批两百条数据写入本地数据库不开启事务时耗时经常在几百毫秒到一秒以上开启事务后能压到几十毫秒量级。不同设备差异会比较大但趋势是一致的批量写场景下事务带来的性能收益非常明显。这说明一个道理事务不只是“保证正确性”的工具它在批量写入场景下确实有不可忽视的性能红利。只不过别把这个红利当成开事务的唯一理由更不能因此就在事务里塞入网络请求那种耗时操作。正确性和性能最终都指向同一个原则事务要短小、聚焦、快速完成。5. 异常处理与多线程并发下的实务指南5.1 异常处理的核心是别吞异常事务代码的异常处理有个常见误区就是catch块里只打一行日志然后什么都没做。虽然事务本身会根据异常情况回滚但如果日志打得不完整出问题时根本定位不到是哪个环节抛了异常、数据到底有没有被回滚。实际项目中我一般会在catch块里记录完整的堆栈同时用一个标志位记录结果方便后续判断。boolean transactionSuccess false; SQLiteDatabase db LitePal.getDatabase(); db.beginTransaction(); try { for (Article article : list) { article.save(); } db.setTransactionSuccessful(); transactionSuccess true; } catch (Exception e) { Log.e(TAG, 批量收藏失败执行回滚, e); } finally { db.endTransaction(); } Log.i(TAG, 事务执行结果: transactionSuccess);另外要特别小心唯一约束冲突。如果在事务里插入的某条数据触发了主键或唯一索引冲突比如收藏夹里已经存在同一篇文章SQLite会立刻抛出约束异常。这种情况下要不要放弃整个事务取决于具体业务需求。有的业务希望跳过重复项继续写剩下的那就要在循环里逐条尝试并在单条失败时排除掉问题数据有的业务要求全部重新处理那就该让异常直接冒泡触发整体回滚。这块逻辑一定要写明白否则很容易出现“删了一条不该删的又留了一条不该留的”。5.2 子线程与主线程的事务边界Android的数据库操作有一个老规矩耗时操作不要放在主线程。事务往往是耗时操作的重灾区尤其批量写入更应该在子线程里执行。不过事务本身有线程亲和性。同一个事务的生命周期应该尽量留在同一个线程内执行。如果在事务中途切换线程执行数据库操作很容易出现拿不到连接或者锁等待超时的问题。正确做法是把整个事务块丢到一个后台线程里跑完然后把结果通过Handler、回调或者协程切回主线程更新UI。还有一个经常被忽略的点如果App使用了多线程并发写库事务期间持有写锁会导致其他线程的写请求排队。压测时我见过因为两个线程同时执行长事务互相等待最终触发SQLiteBusyException的情况。解决办法有两个方向一是缩短事务执行时间二是开启WAL模式并合理设置busy_timeout。使用LitePal的项目建议检查一下配置默认配置在低并发场景没问题但高并发写入时还是要主动做调优。5.3 与异步框架配合时事务千万别跨线程现在项目里普遍用协程或RxJava处理异步任务。配合事务时容易犯一个错误在事务块内调用挂起函数或者异步操作让线程发生了切换。协程切线程可能把执行上下文移到别的线程后续的数据库操作就会脱离事务控制甚至导致数据状态错乱。拿协程来说事务的开启、操作、提交、结束这几步必须在同一个协程上下文中连续执行中间不要出现任何suspend导致的线程切换。如果确实需要等待一个异步结果再决定是否提交就应该先把那个异步操作的结果拿到再进入事务逻辑而不是在事务中间停下来等。6. 常见问题速查表把平时遇到的一些问题整理成一个速查表排查的时候直接对照着看就行。问题现象可能原因解决方案事务里写入的数据全部丢失忘记调用setTransactionSuccessful或者调用位置不合法在所有数据库操作完成后、finally之前调用只有一条数据冲突整批写入全部失败主键或唯一约束冲突SQLite抛异常触发回滚捕获SQLiteConstraintException按业务决定是跳过问题数据还是中止事务嵌套开启事务后数据状态诡异内层事务与外层事务的状态标志互相干扰禁止公共方法自行开事务统一由最外层入口控制事务执行时其他线程写入卡住写锁被事务长期占用缩短事务执行时间事务内不要做网络请求和复杂计算高频并发写入时偶发SQLiteBusyExceptionbusy_timeout配置过短开启WAL模式或调大busy_timeout主线程开事务批量写后ANR耗时操作阻塞了主线程批量事务放到子线程执行结果切回主线程再更新UI在实际项目里这六个问题几乎覆盖了日常使用LitePal事务时能遇到的绝大多数坑。如果哪天线上反馈“数据写不进去”或者“写了一半没了”先照表逐条排查大概率能定位到原因。还有一个不容易被发现的细节事务里如果混用了saveAll()这类批量操作要注意它内部是否已经自带了一些批量处理逻辑。根据LitePal的实现批量保存方法在不同版本里有过行为调整有的版本内部已经会批量提交。外层再套事务不会出大错但最好还是确认一下当前版本的源码实现避免两层批量逻辑叠加产生意料之外的耗时。7. 最后分享一点我的实操体会做了一阵子数据库相关工作之后我给自己定了一条铁律事务是用来保底正确性的不是给代码贴金的装饰。项目里凡是涉及多行数据、跨表数据、或者先查后改的场景事务是标准配置凡是单条读写、只读查询绝不为了“规范”硬套事务。这条规则帮我避开了很多因为滥用事务而引入的长锁和卡顿问题。另一个体会是升级LitePal版本后一定要把项目里的数据库相关用例完整跑一遍。轻量级框架的API变化有时候不会写在更新日志的显眼位置可能只是某个方法的内部行为悄悄调整了就可能影响线上数据。工具越轻越需要我们对自己的数据负责。如果你正打算在项目里全面引入LitePal事务可以从最核心的批量收藏、批量缓存这类场景开始改造配合上面的异常处理和线程模型先跑通一条链路再逐步铺开到其他模块。事务本身不神秘但谨慎对待它永远不会错。