@hussion 说靠平台做广告我相信，说做金融我是完全看不出来。你如果看得清楚，不妨为大家指点一二。

@Totato5749 jvm 上有 groovy 、 Scala 、 kotlin 这么多优秀的语言，何必学 python

@ncisoft 是在下错了，北方交大就是北京交大。

你是北航 6 系的就早点大方说出来嘛，一个在本坛不吹不黑的学校干嘛藏着掖着。
说句实在的， BUAA 氛围简直不能再差。工作中遇到校友，最多就寒暄一句“你哪届的 / 你几系 / 抱歉你们系叫什么名字来着我一直没记住”的就完了。隔壁 BUPT 校友见面那叫一个热情，连 byr id 都要互报一下。

@slixurd
1. gzip 平白耗 cpu
2. json 数据在进入 gzip 并发给客户端这个环节之前也许已经经过了数个内部 rpc 链路或者经过了数个 IO 传输环节，这些环节会受到影响
3. pretty json 的过程本身也会耗费额外的 cpu 时间

对性能有影响是肯定的

吃的不是国家经费，是在座列位纳税人的血汗钱

@ncisoft 看你唠叨半天“我母校我母校”，好奇你母校到底是哪？
ps ：北京交大不是北方交大。

@roychan 对 但是简称还是 buaa 没变😂

redis 漏洞本身不致命，用 root 账户登录服务器并启动程序才是致命的。

@skyim 楼主的场景本来就无法应对高并发，我只是帮他解决了死锁的问题。

把事务隔离级别设为 serialized
或者做一个悲观锁，每个事务开始之前都去获取这个悲观锁，获得了锁再继续往下做事

大概是运气太好？ 手里的一块 P2715Q 和一块 P2415Q 都没有坏点。

@huyinjie 你也不看看 Apple Store 都开在哪。三里屯、淮海路，这都是看颜值的人会去的地方。
理科生在哪？ 在回龙观和张江搬砖。

@notgod 你的观点没有任何说服力。不信你把“底层”二字换成“厨师”看看，一样说得通。

曾经面试一个小公司，手写 jdbc 写到面试官潸然落泪，说是面了这么多终于遇到一个靠谱的。
之后我面试别人时也会加上这道题。

Java 那么多 ORM 框架，刨根到底无非就是对 jdbc 的封装。所以面试时看对方会不会 jdbc ，基本就能看出来他刨根问底的 欲望有多强。

做研究需要 python 、 R 或者 matlab 这种玩具。
Java 是做工程的。

@honam 我上面说编译期被优化不是主要原因。主要原因还是 1 楼说的那样。 A 和 B 操作之间没有 Barrier ，所以 B 读不到 A 的更改。给 ready 加了 volatile 后就产生了一个 Barrier ， B 就可以读到了。

@honam 周志明「深入理解 Java 虚拟机」，里面有一整章是讲这个的。

@honam 这个循环中的 ready 在编译后似乎会被优化成局部产量，初始化一次后就不变了，永远拿不到其他线程修改后的值。