残页 comments

Results 114 comments of


                                            残页

[TODO] Bring `XSharedPereference` FULLY back to support old modules

@etmatrix /data/data is encrypted, so it is unusable before the user unlocks the device. We don't want to provide an API that's not completely available, so we closed this issue.

这次试试用故事解释一下：在很久很久以前，某一台机器里有成千上万个线程，他们勤劳的工作着，处理着那些复杂的任务。某一天，一个线程2333要将一个变量a的值加一，2333读到了a的值为1，现在a的值应该为2了，2333将a的值写为2，然后就离开了，可是他不知道，在他计算的时候，其他线程也动了a的值，执行的也是a++，现在a的值发生错乱了！后来，程序员们设计了一种锁机制，当有线程需要操作共享变量时，必须申请一把锁，只有申请到的线程才能去操作，其他线程则等待锁。又一天，还是线程2333，还是操作a的值，不同的是需要申请锁，线程2333发现这把锁被别的线程占用了，于是等，可等了很久还是没拿到锁，2333等到了天荒地老。程序员们见这样可不行，于是实现了一种新的方式：当线程需要当前值去操作该值时（比如a++），先得到a的值，计算出a+1的值，然后将之前得到的值和当前a的值比较，如果相等就更改值，否则重新来过（注：这一步应该是原子操作，比如CAS，否则还是会乱）总结： - 第一个办法就是悲观锁，悲观地认为一定会发生并发修改，所以用一把锁阻止其他线程同时去操作 - 第二个办法就是乐观锁，认为发生并发修改的几率很小，所以只在最后去判断是否可以修改，不然就重新来过（其实还有ABA问题什么的）推荐文章： [悲观锁和乐观锁](https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513993&idx=1&sn=6a384b790382411bb0ecbf87ffe25bb8&chksm=80d67c4ab7a1f55c02f87233ac7cba24abcf409d3dc1b048098a55aaf0cffef668c581d46c31&scene=21#wechat_redirect) [编程世界的那把锁](https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513653&idx=1&sn=e30c18c0c1780fb3ef0cdb858ee5201e&chksm=80d67af6b7a1f3e059466302c2c04c14d097c1a5de01cf986df84d4677299542f12b974dfde3&scene=21#wechat_redirect) [加锁还是不加锁，这是一个问题](https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513692&idx=1&sn=ef2416a4bb96d64db77e32d5b4c7967e&chksm=80d67a9fb7a1f3898e513cc1d9e96841610bb84aed2dc24cab2d403e74e317e3c447e45e7611&scene=21#wechat_redirect)