@standin000 #32 视频没问题，30 帧足够了，玩游戏不行（真锁 30 帧也能玩）。hyper-v 没有直通，但是有更方便的显卡虚拟化，它的主要问题是有显卡但没显示器（显示器只能是远程桌面，不提供其他连接方式）。

好吧，我写错了，addAll 不能链式操作，要想一句代码就完成的话，只能使用原先那段很难看的代码。为了可读性建议拆分语句如下：

TreeSet<Student> tempSet = new TreeSet<>(Comparator.comparing(Student::getName));
tempSet.addAll(studentList);
studentList = new ArrayList(tempSet); // 或者 studentList = tempSet.stream().collect(Collectors.toList())；

尝试换一种写法：

studentList = new TreeSet<>(Comparator.comparing(Student::getName)).addAll(studentList).stream().collect(Collectors.toList())

原理是，利用 Set 不允许添加重复元素的特性（添加重复元素时忽略，不是报错）来去重。具体操作是，将当前集合的所有元素尝试全部放入一个 Set 中（用哪个 Set 的实现类取决于如何判重），然后在将完成的 Set 转换回原来的集合，在将元素放入到 Set 中的时候，重复元素会被排除掉。但是你抄这段代码可读性是真特么差。

@shangwuli 闲着无事，看了你链接的那篇文章，发现那特么在放屁，你要学他铁定被坑。那个文章，第一章是套话，第二、三章对 PDCA 的解释还不错，但是第四章就是胡扯了。第四章说的实施方法，跟 PDCA 没有任何关系，那压根也不是可以实施的方法，根本就是随便找了些语言组织起来就放那里了，你翻到 20 年前讲解软件工程、CMMI ，甚至瀑布开发的文章，都能找到类似描述。

PDCA 循环，或者说戴明环，或者说 8D ，在生产制造行业是有完善的实施体系的，如果真要用，要找专业教练培训一下。不是啥大培训，三天就够了，不过培训费用应该不菲。不过软件行业，一般是参照而非使用 PDCA ，最好还是做专门的 SCRUM 培训，哪怕是国内魔改的培训，也有用。

层叠模式下的存储，假定是这些快照，10 点的快照->11 点的快照->12 点的快照，12 点快照要依赖 11 点快照，11 点的要依赖 10 点的。如果这时候你切回了 10 点的快照，那么 11 点、12 点的快照就作废不能用了。

当然有方法能弄成 a -> a1, a -> a2 ，a -> a3 ，在 a1 、a2 、a3 之间来回切换的快照存储方式。不过这种形式下你得手动保存和开启快照了，说句实话，手动保存快照，要比切换虚拟机慢，而且可能慢上好几倍的时间。

@123go Hyper-v 的快照是类似于 Docker 镜像的层叠模式，其他虚拟机的快照估计也类似。这种方式不适合做来回切换。

全程工作在唯一一个虚拟机环境下是可行的，hyper-v 虚拟机除了 ctrl+alt+* 组合键用不了、（因为只有远程桌面连接这一种方式造成的）锁 30 帧之外，跟宿主机就没区别了。多个虚拟机随时切换就太困难了。

scrum 天生就是 PDCA 循环，如果你们用 scrum 但是没走出来 PDCA 循环，那说明你们并没有真正的在用 Scrum 。这种情况下给什么方法论都没用。提示一下，PDCA 和 Scrum 的精髓是：每轮只解决最优先的部分问题（通常绝大部分问题都是留给后面）；根据以前的效率指定之后的计划（意味绝对不会有效率低下这种说法)；没全部成功就是失败（同时做失败了也算做了）。

@dqzcwxb 没先搞明白事务，就直接上分布式事务，就容易出现你这种理解偏差（说直白点就是没学会走就去学跑）。分布式事务的目的是什么，是要保证分布式场景下的数据一致性，那如果分布式流程中的单个环节都无法保证一致性的话，总体场景怎么可能有一致性。

不光 TCC ，除了两阶段提交之外的大部分分布式最终一致性方案，在分布式流程环节，都不依赖数据库。那实际上就不需要明说，都特么跨数据库了，还怎么依赖数据库。而那只是分布式流程环节不依赖数据库，单节点内部，还是需要强一致性的，而强一致性最好的方案就是关系数据库。单节点环节内部需要强一致性，这点也是不需要明说，因为通常能接触到最终一致性方案的，不会是像你这样事务一致性都不懂的人。

@dqzcwxb 你的文字理解能力实在是有限

@dqzcwxb 给你补充一下，TCC 模式是不依赖于本地关系数据库的 ACID 事务，但人家可没说不要求本地事务，你要不用关系数据库的事务，就得自己参照 ACID 原则做本地事务。

@dqzcwxb #1 跨库事务或者分布式事务从来都是伪命题，最后都要放弃事务一致性改成最终一致性。而最终一致性的前提是单节点上的事务一致性。至于你说的 TCC 模式，虽然我是第一次听说，但随便一搜就能确定它在单节点上还是事务一致性。

@dumbbell5kg 没有明确的说明，只是从经验上来说是这样，你可以看看 TransactionManager 的实现类。

你说的这个 request handler ，传输层用得还是 TCP ，它只是应用层用的 http 协议 。你自己的服务器，并不是直接运行在 TCP/UDP 协议上的，它也需要有专门的应用层协议。你照着 http 协议，搞一个带路由功能的协议即可。单纯的协议可能很难，但是要是把协议跟你开发用的工具结合起来定义，应该会很简单。

关系数据库的事务，跟非关系数据库的事务，不是一套体系，不能一起看待。比如说 Redis 的事务仅仅代表多个命令同时执行，都没回滚的。

Spring 的事务管理体系，是完全基于关系数据库的（它貌似压根没有 ORM 当中 O 层面的事务管理，完全用得是 R 层面的事务管理）。

@kongkongye 约定优先于配置，不是约定代替配置，你要不乐意，完全可以手动配置自己搞。你所看到的复杂，跟约定优先于配置没关系，是配置本来就这么复杂，约定是降低，而不是增加了复杂度。你现在的看法，举个例子来说就是：不怪路本来就难走，而怪修路的没把路修好。