晚上十一点半。屏幕一暗。脑子里突然就跳出书里那句“数据更新并发冲突”。俩程序同时去改同一条数据，系统可不会傻乎乎地直接覆盖。得翻版本号。接着等？两边揉一块儿？还是直接甩个冲突警告？作者硬是把这套冷冰冰的代码逻辑，嚼出了点过日子的人味儿。道理是这么个道理。不过说真的，谁真在凌晨盯着并发日志看啊？也就我这种被需求逼到墙角的人，才会对着黑屏发呆。
咱们这日子，说白了不就是个多线程跑着的程序嘛。白天盯项目进度，晚上回一堆家人微信，周末还得硬着头皮去啃那些“必须学”的网课。谁不盼着自己能扛住高并发？既要稳当，又要利索，最好连个卡顿的死锁都别碰。可现实呢？它专挑节骨眼上给你添堵。刚排好的计划说变就变。满心期待啪叽摔在现实上，那股子热乎劲儿，转眼就被疲惫浇灭。几件事儿同时拽着你，大脑CPU直接飙到100%。界面卡死。进度条跟焊死了一样动都不动。微信群里叮叮当当弹出来七八条消息，需求文档又改了第四版。这时候谁要是真能把多线程跑成单线程……那才叫反人类。我觉得吧，咱们普通人，能勉强维持个“假死不死”的状态，已经算超常发挥了。喘口气，真的。
翻到《Visual C#2008开发经验与技巧宝典》里讲异常拦截的那章。作者压根没跟你扯怎么把错全抹了。而是手把手教怎么把它兜住。碰到没招儿的报错，程序也不会直接蓝屏跑路。先默默记个日志，拍拍土，接着往下跑。书里反反复复就一个理儿：哪儿疼治哪儿。别把简单事儿搞复杂。关键代码甩出来就行，剩下的全交给运行环境自己去转。搁以前，我特较真。觉得生活里冒出来的岔子全是bug，必须立马打上补丁，最好能一键回档。后来才咂摸过味儿来。有些局，根本无解。好比心里既想赖在熟透了的城市不出门，又馋外面的新鲜风景；想对身边人掏心窝子，又怕打乱人家原本的步调。念头一股脑儿往上涌。你根本挑不出哪个不对。只能干看着它们互相抢内存。拿2008年的C#书来指导现在的生活？多少有点刻舟求剑的意味。但那种“兜住就行”的笨功夫，倒确实管用。
有阵子，我疯了一样迷恋“优化”这俩字。日程表排得跟铁板一块儿。微信列表删得只剩能办事的人。连心里起个波澜，都想拿理性拿网兜住。给自己立了死规矩：不拖沓，不内耗，干啥事儿必须见个准谱。直到有回加班熬到半夜。手机啪叽没电。电脑也自动睡死过去。屋里就剩空调外机在那儿嗡嗡喘气。窗外的路灯把影子拉得老长。桌上还搁着个凉透了的便利店饭团。就那会儿，我猛地发觉。自个儿弦绷得太紧了。代码写砸了能回滚。日子可没有倒带键。只能硬着头皮往前赶。那些被我硬按着头同步的线程，早就在后台偷偷报警了。人就是这样。越怕出错，越容易把橡皮筋拉到极限。啪一声。断的还是自己。
书里倒有个挺实在的法子：对付并发冲突，硬刚同步不如设个合理的超时时间。歇口气。让那边的进程先跑完。过日子其实也这德行。觉得被各种破事儿撕扯的时候，真不是咱不够拼。纯粹是后台挂的任务太多了。干脆允许自己把某个计划先挂起。允许某些关系别那么实时在线。允许日程表上大片大片地留白。这不是认怂。是给自个儿的系统腾点喘气的缝儿。咱们老把效率当尺子量日子。却忘了有些东西，本来就得慢慢加载。缓存能清。文件能压。可那些没顾上消化的情绪，那些没赶上的局，留着就留着呗。原封不动挺好。当然，超时时间设太长也不行。总不能真让日子停在原地。偶尔报错，就当系统自我清理了。跑通一次，算一次。
我啪地合上电脑。懒得再去琢磨什么完美解法。明儿个指不定又撞上什么新冲突、新报错。不过，真没必要次次都去套try-catch。有时候，瞅着报错红框亮那么两秒，随手一关。接着干手里的活儿，就挺够用了。日子嘛，本来就不指望它能一次编译全绿。能稳稳当当地跑起来，就挺不错了。反正我也没指望它能成什么史诗级大作。能做个不闪退的实用小工具，就知足了。