有能直接抓包的 app

主力游戏机 无 service 常驻，无微信等国产软件，2g ram 512 zram,流畅

@Levox 你不 root 用的的是 zram 没有磁盘 io 不会导致你手机卡。neon 压一下就进去了。

………这你不发贵知道你内存是怎么用的？

cat /proc/meminfo

@nananqujava 牛逼了大兄弟

所有的 Python venv 方案都要改 VIRTUAL_ENV 环境变量

program: microblog
里面可以加环境变量
加的是 VIRTUAL_ENV
你仔细看看 venv/bin/activate
都干了啥

@styx 你不说我还真记不起来 TSO 这个事，得好好谢谢你。

@styx 是我考虑的不仔细，随手写的确实没考虑 x86 STORE 保序的问题。

@yangxin0 看来我说的不够详细，内存屏障是解决 LOAD/STORE 乱序的问题。
例如这种情况：
a = (char *) melloc();
dev.buff = a;
mb();
dev.flag = 1;
很好理解吧，填 buff，置 flag。
另一个线程发现 dev.flag == 1 就开始取 buff。
但是 cpu 的执行单元是乱序的（注意：假定编译器得到的顺序是对的，这里还有个 Optimization Barrier 的问题），如果不加屏障就可能是这样：
dev.flag = 1;
dev.buff = a;
另一个线程发现 flag 置 1 了去读 buff，此时 buff 指针可能还没来得及填，直接一个段错误歇菜了。
内存屏障实际作用是：保证 MFENCE 指令前的 LOAD/STORE，一定在 MFENCE 指令之后的 LOAD/STORE 指令之前完成。
回到你的理解：
写 thread 可能正在进行一个非原子的+=1
首先他只有一个线程在加，就算不是原子加那也不会影响别人读数，最多读的不是准确值，但是绝不会一直是 0。
要是有多个线程再加同一个数，就算不是原子加，最后肯定有 core 会成功写到 cache 上的，也不会一直是 0。

题主说的真没错，不是什么高深的问题，就仅仅是编译器把
i += 1
给优化掉了。
仅此而已。

@yangxin0 内存屏障不是解决 cache 一致性问题的

内存屏障是解决顺序一致性的问题，怎么到了楼上的说法怎么全是解决 cache 一致性了。

@yangxin0
mov i, %eax
add %eax, 1
mov %eax, I

兄弟你用了 venv 你环境变量却没设置啊

thumbdata3 是 aosp 相机和图库(com.cooliris.media)存放缩略图的缓存，其中每个缓存占 10k。
每个原始的图片或视频都会有个自己的 ID，这个 ID 是 MediaScanner 给出的。问题是 MediaScanner 不止扫描图片视频，还有音频等媒体文件。所以对于我们要生成的缩略图来说这个 ID 就不是连续的。且不一定是从 0(一个小整数)开始的。
图库就会把缩略图放到 thumbdata3 的 ID×10k 的位置，这样读取缩略图的时候就不用再繁琐的查数据库，直接去对应偏移找缩略图。
回到我们刚才说的问题图片 ID 可能不连续，并且是个很大的数，比如 ID 为 10000 的媒体文件的缩略图，就在 thumbdata3 的 100m 的位置上，也就是说 thumbdata3 至少要有 100m。但是是这样吗？这个问题请参考一楼的链接。
可以用 du 看一下真实占了多大，如果数很大…我再来告诉你为啥

@Trim21 吃这行饭的，最怕 bug 单上问题复现路径不明确

@fulvaz 哈哈哈哈这个帖子有好大的怨气啊，容易教坏老实人

less 快捷键 F (shift + f)