@huruwo 唔，这就有点复杂了不是，而且字节码并不是能够一定反编译回 Java 的，所以还是推荐在字节码级别上比较。

@asanelder jdk 就用 Oracle JDK 8 就行，我估计不太会有 IBM J9 这种诡异的版本。
反编译的话，你可以试试 javap，或者 Bytecodeviewer，至于对比估计还是要手动对比一下。
如果你有精力的话，用 ASM 自己写个程序对比一些就行了~

1. 这个方案最可行。不过如果使用了其他的编译器插件的话，就还要进一步猜。
2. 这个方法不太可行，原理上可以反编译，但实际上有些糖化语法和常量内联没法找回最原始的代码。

建议先编译源码，不行了再反编译。

楼主说的挺好的呀，只不过现在越来越不倾向于这么做了。
过去一根线一个用途，现在一根线上跑所有数据。
这样能够有效降低你所说的研发成本和运维成本，而实际上压缩率没有你想象的那么重要。

截止到现在分别是 2 年，1 年，0.5 年，1 年。
每次换工作都没有影响。

给每个消费者弄一个 Queue 就行了。

我觉得是好事，任何对于投入产出比有利，降低社会必要劳动时间的行为，都是合理的。
从另一方面来说，应对诸如 @ajaxfunction 这种实际上应该被淘汰的 API 工人，应该使用温和的疏远方式。
应对保守型的同事是一个必要的功课，而这个正是跨向领导型人才的必要课程。
祝好运！

@stabc
在银行的角度，如果这个小额账户真的没人用，或者被遗忘了，就可以通过这种方式来清空账户，然后触发销户。
在你确定要用了的话，银行当然也乐意把费用退给你~

理论上，蓝绿发布就可以了。
实际上，保持代码向下兼容，然后加配置或者控制前端页面放量。
核心上，只要保证最外层的业务在最后开启就可以了。

有必要性。
但是看你们团队的取舍。
单元测试用于确认你的代码符合你的 design，所以是一份非常有价值的文档和设计。
一旦出现变更，单元测试和书面文档比，性价比非常高。
尽管如此，如果测试资源便宜的话，或者变更时效性要求非常高的场合，都可以被省略的。

这个 case 也太真实了吧=。=
一个结论，不具有一般性：
1. 用差不多 2 个小时看一下启动日志，然后看一下启动时期一些中间件的初始化耗时情况。
2. 基本上这里的结论都没有啥用，然后会在下一个发布时间搭车加一些日志，测量一下初始化的问题具体在哪里。
3. 发现真的解决不了问题，然后跟中间件说把发布启动超时弄长一点。
4. 然后他们就会比较关注这个应用，跟你说哪里可以改进一下。

@Counter P7 有，P6 没有。但是以什么价格给的就不清楚了，毕竟内部估值也已经很高了。

@szzhiyang 因为 JVM 字节码有解释器模型。。而 Go，不是也有 interface{}的 magic 嘛~

@xiangyuecn 不对，因为 tail 是个 mutable 的，所以每次拿的时候就要存下来，否则就会存在变化的可能。
你可以用一个新的 ref 去引用你新拿到的 tail，但是如前所说会多一个 slot 。

p = (t != (t = tail)) ? t : head;

等价于：

val tmpT = tail;
p = t != tmpT ? tmpT : head;
t = tmpT;

@chairuosen 正因为这不是业务代码，所以才要剩下一个 slots.

@amiwrong123 写错了，a = 1 返回 1 。

@amiwrong123 你说的我完全没弄懂。。
我给你简单解释一下：
t = tail 是用来获取当前最新的 tail 。
(t != (t = tail)) 就是检查一下 t 是不是最新的 tail，同时将 t 更新为最新的 tail 。

在 Java 中，赋值语句返回所赋的值，比如 a = 1 返回 a 。

@chairuosen JDK 里这种写法很多，这样编译的时候会减少 slots 的占用。