@letitbesqzr 首先营养跟不上。政治的偏向太明显，看不进去。其他有推荐的吗？

@Foxkeh 我们也是 从 4 月份开始 第一次实行大小周。。。 感觉今年部门管理上越来越大胆，不怎么考虑员工的意愿了。
ps：周六有下午茶（弥补措施），这次 51 加班也有，刚刚参加。。一些水果、切块盒装，还有泡面、几样零食。pps 吃泡面的不少。。。

我的理解就是#7 说的：最终一致性就是没有一致性。
首先，最终一致性是基于一致性概念衍生的。本来一致是一个原子的概念，一致=没有分歧，没有说部分一致的。
在分布式场景下，一致代价太大。基于 cap，为了 a，只能放弃 c，但业务场景又不能完全放弃。然后就想办法把 c 分级了，就是一致性模型。然后把一致 改名为强一致了。其它的一致性模型都是部分一致的（就是不一致）甚至完全没有一致性保证。其中“如果经过一段时间后要求能访问到更新后的数据，则是最终一致性”（引用自 http://www.blogjava.net/hello-yun/archive/2012/04/16/376744.html ）。
一致性模型中，基于读写及它们的开始时间结束时间，及它们的进程关系这些要素来定义约束，命名一致性模型。非强一致性的模型都只能保证部分一致。无保证的场景就说是最终一致的（可以基于超时额外增加验证补偿机制）。
最终一致性只是部分一致性的一个美化的名字。把不一致说的好像是一致的。不知道是为了忽悠谁。

分布式事务的一致性还是事务的一致性，即业务层面定义的一致性。分布式事务相对与单机事务的难点是：因通信不稳定，参与事务的各个‘进程’如何对状态达成一致。这是个共识问题。
至于 CAP，通常网络 P 很可能发生，无法避免（看到有人说谷歌自建网络非常稳定，不会出现 P ）。所以只能在 CA 上做权衡，C 强一点，A 就弱一点。CA 好像是某个概念（延迟？）的一体两面。建议参考 jepsen.io/consistency，https://www.zhihu.com/people/zhangshuai89/posts

@hengyunabc
‘具备强烈的技术好奇心，专注微服务、服务网格、分布式消息队列、NewSQL 、大数据、流计算等领域至少 3 年’

楼主经历没有这个也可以吗？非 985 也没有这个经历的有机会吗？

@Aresxue 额（︶︿︶）=凸

我说的就是 hash tree 。刚刚搜了下，已经有这种数据结构了。

@Aresxue 是的，问题还很多。你问的问题，有一些不成熟的思路。我初始想法是把现有的 ConcurrentHashMap 中的红黑树（链表不需要）在某些情况下换成 ConcurrentHashMap （ hash 攻击不在情况内）。

我希望分层是基于密度分布的。也就是基于 hash 的分布而分布。关于分多少层和在哪里分层都应该是基于分布比例来。就像 28 法则里面的 2 可能还适用 28 法则也可能不适应了。基于单个 bin 中数量与整体容量的比例来估算。

hash 有 32 位，值范围 1<<32 。假设 table 的长度 32，容量 24.假设 24 个中有 8-12 个落在一个 bin.通过统计同一个 bin 中 27 个位的分布，取其中分布最均匀的 4 位 hash 到一个长度 16 的 table 。（分布均匀度计算方法：如指定位 1 的比例；如第 7 位 1 与 0 一样多，这个位分布就比较均匀。应该有好的数学算法）。

假如容量 24 已经满了后，又插入一个，这个时候应该扩容了。该扩容 32 的表还是 16 的表？

如果新插入的落入了 16 的表，而 16 的表容量 12 还没满的话，应该不用扩容。如果 16 的表容量 12 已满的话，应该扩容 16 的表。

如果新插入没有落入 16 的表。应该技术除了 16 的表的负载，方便起见可以把 16 的表的负载排除在 32 的表之外。如 16 的表中有 12 个，32 的表中有 12 个，则 32 的表的负载为 12/32 或 13/32.

也就是说对于在哪里扩容的问题，把 bin 是 map 的负载排除计算容量，来决定 table 是否要扩容。有个问题，主 table 扩容后子 table 怎么办？

对于分层，是根据单个 bin 占重容量的比例或者 8 个以上就用子 table （与前面按密度分配矛盾）？（衡量标准是计算用子 table 的优缺点）；

上面只是记录些我的思路，写的不清不楚（本来也没想清楚）。打扰见谅，可以不用回复。

@Aresxue 是的

我是希望能通过分层 Hash 来解决这个问题。并不是依赖实现 hash 碰撞率极低的算法。

如在现有实现下，假设是 len=32 的 table 。当 hash 碰撞时，说明 hash 后面 5 位是相同的。如果 bin 再通过 hash 另外的 27 位，均匀分布的概率相比 32 位时应该会更大。

而且（我感觉很矛盾） 32 位时用 HashMap 平衡时间与空间，为何里面的 bin 不能用 HashMap，而用链表或红黑树？

@yeqizhang 我没有装 jdk7，看了下网上的文章及文中贴出的关键代码 transfer 方法。下面是我根据文章的理解。

关键代码 e.next = newTable[i]; newTable[i] = e;

transfer 中 table 是共享的，transfer 中只修改了 table 中 node 的 next 。next 会指向 newTable，newTable 也 可能 会通过 next 传播到线程外。

说可能是因为 线程 A 对 next 的修改不知道什么时候传播到线程 B 。线程 B 读到的 next 指向原来的 node，也可能指向线程 A 中 newTable 的 node 。

假设 table 中有一个 bin 是 a->b->c->null 。正常情况下，单线程 A 会把这个 bin 移到 newTable，变成 c->b->a->null 。

多线程情况下。线程 A 遍历到 b 了，产生的新链是 b->a->null 。

线程 B 开始遍历，这个时候线程 A 的修改还没传播到线程 B，所以线程 B 还是按 a->b->c->null 遍历。

当线程 B 移完了 a，新链是 a->null 。开始移 b 的时候，线程 A 的修改传播到线程 B 了，这时线程 B 就会按 b->a->null 遍历。

线程 B 按 b->a->null 遍历到 a 后，产生的新链就是 a->b->a 。这个就是环了。

即，正常按 a->b->c->null 遍历，翻转成 c->b->a->null ；多线程情况下，遍历到 b 时，变成按 a->b->a->null 遍历了。翻转的结果就是 a->b->a 了。

总结

单线程情况下 链表翻转了。多线程情况下，前面的线程正常翻转，后面的线程翻转到半途中链表已经变成了翻转后的，这时再翻转就是回头路了。

@Hurriance 链表也可以不加锁，如链表本身就是线程安全的。但这样得不偿失。

我说不需要加锁是从 ConcurrentHashMap 提供的接口语义看，key 之间没有关系，更新锁定 key 就可以了。

@iEverX
但实际用的链表导致 key 之间有关系，维护起来需要锁。如果某些情况（ hash 碰撞但不完全相同）改用 ConcurrentHashMap 代替链表保存数据是不是有#4 说的更好的效果。

与数组是不同的，这个按 hash 分布的密度分布分配空间，不均匀分布。数组按 hash 范围分配空间，均匀分布。我假设是说明一个可以优化的场景，就像链表长度到 8 转红黑树，我的意思是说 hash 不完全相同转 map 。

@smilekung 恩
但假设不用链表，也用 ConcurrentHashMap 呢？

不考虑 hash 完全相同的情况。也就是假设没有 hash 碰撞，是否可以完全不用锁？

就像现在的 ConcurrentHashMap 是每个 bin 一个锁，如果没有碰撞就是完全并发了。

我发现与 1.6 版本可以单个 segment 扩容不同，1.8 版本是整个表扩容。

我觉得在 hash 分布不均匀的时候，只在密度大的地方扩容，应该可以节省空间。

且用 map 替换链表应该也可以提高并发读。除非 hash 完全相同才用链表或红黑树。hash 不同时用 HashMap 是最快的。

@guyeu -_-|| 是 ConcurrentHashMap 。之前也有锁，segment 继承 ReentrantLock 。

之前是按 segment 锁的。segment 里面是 table 。jdk8 版本支持的并发度更高了。每个 bin 一个锁。

ConcurrentHashMap 对单个 KV 对的操作应该是不需要锁的（不同的 Key 之间是没有关系的，Map 只需保证对 KV 的 CURD，单个 Key 可以用 CAS 不需要锁），对 size 这种跨 Key 的接口提供的都是快照，不准确的。

我想是因为扩容才需要锁定，否则转移的时候会丢失。

@sagaxu 双写通过副本提供完整性的可靠性、校验和提供数据完整性验证的某种可靠性。

完整性与 可靠性是两码事。

双写 提供完整性的保证，不是提供完整性。MySQL 脏页刷新通过双写保证了页的完整性，不是页数据的完整性。数据的完整与双写提供的完整保证是不一样的吧？所以我形容成 完整性的可靠性。

@PureWhiteWu 是部分可靠吗？

@lhx2008 在规定的条件下，完成预定功能的能力？

@GeruzoniAnsasu #68 查表也是一个更简单的 y=f(x).

@jackchao7432 我感觉到被你嘲讽了。这个问题不能问吗？我是随便问问，有兴趣参与讨论下，没兴趣可以不用回复。

@wshwwl
1 、观点是 选择。
2 、观点是 转移。这个部分认同。前面图书馆的例子，是因为分类整理的时间转移了后面查找的时间还是制作书架的时间？

是我钻牛角尖了。

@www5070504 #33 我也觉得，就是突然有个念头，随便问问。

@xiaobai332 #36 就是这个 style

@favourstreet #37 没怎么看懂。门电路在时空不同位置没有区别，并没有回答问题吧？是 a 和 b 两种可能吗？（我没理解）

@cmdOptionKana #39 这个例子和#9 图书馆的列子类似。书不像衣服需要折叠。但也达到同样效果了。折叠不是问题点。

@yangzhezjgs #43 这个针对计算机好理解。你的意思是因为‘重复’。

@hoyixi @Blacate 这些列子直观的我没有一点疑问。但我对应不起来。我要对这些例子问‘为什么’。会不会有人想打我？_(:з」∠)_