@amiwrong123

* Registers this channel with the given selector, returning a selection
* key.
*
* <p> An invocation of this convenience method of the form
*
* <blockquote><tt>sc.register(sel, ops)</tt></blockquote>
*
* behaves in exactly the same way as the invocation
*
* <blockquote>
<tt>sc.{@link
* #register(java.nio.channels.Selector,int,java.lang.Object)
* register}(sel, ops, null)</tt></blockquote>

还是我原来说的，你仔细看你的代码：

//sk.interestOps(sk.interestOps() | SelectionKey.OP_WRITE);
socketChannel.register(selector, SelectionKey.OP_WRITE); 👈

sk.attach(ByteBuffer.wrap(sendStr.getBytes())); 👈

注册写，attachment 置 null，然后调用了 attach()，attachment 为 sendStr 。

//sk.interestOps(sk.interestOps() & ~SelectionKey.OP_WRITE);
socketChannel.register(selector, SelectionKey.OP_READ); 👈

注册读，attachment 置空，没有调用 attach()，所以 attachment 依然为 null 。

@amiwrong123

你可以认为

socketChannel.register(selector, SelectionKey.OP_READ);

其实就是

socketChannel.register(selector, SelectionKey.OP_READ, null);

第三个参数就是 attachment

读文档呀。

Selector 持有两个 Set，Keys 和 SelectedKeys，后者只是前者的子集。
每次调用 select()，会把前者中的部分添加到后者中，而不是重复注册生成新的 SelectionKey 。
register()也是一样的，如果已经在给定的 selector 注册过，那么方法只会对 interestOps 和 attachment 进行覆盖。

key.attach()会设置 key 的 attachment 字段，而一个 key 和一个 channel 绑定，所以你的理解是正确的。

socketChannel.register(selector, SelectionKey.OP_WRITE); 👈

String sendStr = "您的消息'"+sb.toString()+"'我已经收到了";

System.out.println("接下来 attach 的是："+sendStr);

sk.attach(ByteBuffer.wrap(sendStr.getBytes())); 👈

可以看出，你调用 attach()在 register()之后，所以 attachment 不会“丢失”。

返回 nil 只是说明 redis 根本没有执行此事务（命令队列）。
按照官网的说法，redis 事务中的命令要么都被执行，要么都不被执行，所以它是有原子性的。

什么？你说语法错误？语法出错了那不就是乱码吗？乱码又不是命令，无所谓执行不执行。
不支持复杂操作？那跟原子性有关系么？
没有自动回滚就不能拥有原子性，我 redis 并不认同（

「即使一个人是全才、什么都会，他每天也只有 8 个小时工作时间」

HR 暗示公司不加班，给不到 15K 。

getUsersGracefully()

上海、9106、5.5k 。
跟富士康也差不多了。

水军还给 5 毛钱发帖费呢，对不对？

@shintendo
理论上确实不行，哈希之后信息丢失了。
但是现实中文件大小可以提前确定，而且有固定的格式，所以还是有一点可行性的。

最重要的是足够好笑。

淦，那我这精神分裂岂不是没救了。

可以啊，就是效率极低而已，甚至宁现在就可以写一个。
每次生成一个随机文件，然后算一下 MD5/SHA1 是否相等，XD。

要么解码效率低，要么压缩率低，要么解压软件体积大，不可能三角。

一般人会卡在 MPS-31816，而火狐用户会卡在谷歌无痕。

public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}

如何定义「影响」？

Hackers Find New Ways to Use .EXE File Against macOS to Launch Malware that Bypass Protection & Steal Data

https://gbhackers.com/hackers-find-new-ways-to-use-exe-file-against-macos-to-launch-malware-that-bypass-protection-steal-data/

统一之后就没绩效了呀。
显得自己什么都没干，那怎么行。

这些系统设计之初就没考虑到互通的问题，已有的成果又不能轻易放弃。
那么，与其让老爷们费神费力和多个部门协调扯皮，还是多麻烦麻烦你比较方便。

>我们又知道 C++是可以跑在 JVM 上的

反正我不知道 = =，我只知道出现过几个 c2j 转换器，不过貌似理论上是可以的。
JVM 的底层结构又不影响顶层语言怎么实现，用别的办法去模拟就好了（比如增加一个 list 属性）。

你非要深究的话，Python 支持多继承，你可以查查看 Jython 是怎么实现的。

PS：java 本身就能通过接口实现多继承。

@liliumss 一般的就是 JSR133 和其他的官方文档，书籍的话就是《 Java 并发编程实践》这种。
如果要深入分析，那就需要科班的基础知识（编译、汇编、操作系统、硬件等）和一些直觉与经验，还要对 JVM 有一定的了解，这就不是光看文档能学会的了。

@liliumss JMM 并没有规定对非 volatile 变量的修改对其他线程完全不可见，不存在什么“互不影响”。
我们只能说这是不确定的，在不同的平台上于不同的时间执行会得到多种结果，出现什么情况都不奇怪。

第一个 demo，如果某 CPU 还没有把修改后的值写入 L1cache，或者 CPU 根本不保证缓存一致性，那么修改还是可能不（立即）可见。

第二个 demo，Thread4 会无限循环，是因为 JIT 的神奇优化，你把 JIT 关了程序就可以退出了，而 JIT 并不是必须的，各版本的 JIT 也不尽相同，所以还是可能可见。

java -Xint DemoApplication
Thread3 start
Thread4 end
//然后程序退出

所以这根本不违背 JMM，没有什么好纳闷的，真要纳闷的话，那些凌乱的底层原理可太多了。

如果要深究为何如此，那就与 JMM 无关了。

JMM 和 JVM 的内存结构不是一一对应的关系，或者说他们定义的不是一个层面上的事情，
所以不要去用堆栈元空间什么的去分析。

JMM 什么时候刷新缓存到主存，什么时候读取主存，如果不加 volatile，那么都是不一定的。
你多执行几次就会发现执行结果还可能是这样：

Thread1 start
Thread1 count:1
Thread1 count:2
Thread1 count:3
Thread1 count:4
Thread1 count:5
Thread1 count:6
Thread1 count:7
Thread1 count:8
Thread1 count:9
Thread1 count:10
Thread1 count:11
Thread1 count:12
Thread1 count:13
Thread1 count:14
Thread1 count:15
Thread1 count:16
Thread1 count:17
Thread1 count:18
Thread2 start
Thread1 count:19
Thread1 end
Thread2 count:10000
Thread2 end