说创业的人自己是创业的吗？

要不然里面多少坑呼喊别人去踩？

显然是用现成的

B 站斗鱼啊什么的

jit 这么差我怀疑作者的测试方法或者是所使用 jvm 本身的优化是不是有问题

主要看那些常见的，比如 hashmap 啊，threadlocal 啊之类的东西

做到能口述原理，比如扩容怎么实现，什么场景下实现，并发为什么会有问题等等

多搜这个东西相关的面试题

貌似数据类型是时间序列, 那有比 mysql 更好的解决方案

至于如果真的用 mysql 怎么搞

首先就像你说的, 每分钟一个点, 一年数据存死了, 怎么办?

考虑业务妥协, 比如

1. 真的需要一年前的数据吗, 业务价值在哪, 谁会去用它?
2. 六个月以前的数据聚合行不行? 十五分钟一个平均点
3. 六个月以前的数据换存储方案(比如文件), 要查可以, 接受查询比较慢
4. 这个数据最后会怎么用, 是聚合还是真的需要一分钟一个点去展示, 如果是聚合那定时任务聚合好直接用聚合好的数据展示行不行


(最后像是这种统计类的数据, mysql 存储全量肯定是不行的, 一般都是存个最近几天的数据, 查起来快, 历史数据全部扔到类似文件存储, 存储量大查询满. 另外 50 亿的数据分库分表也是可以搞定, 但这么大的成本为了存这个数据得考虑考虑投入产出比啊

如果是专门想解决 SimpleDateFormat 的问题

那答案是不用这个类, 有很多更好用的替代类

还有那种，两个人想知道谁的收入比较高。

存在一种方法既不需要第三方介入，两个人也可以不用知道对方收入的方法

。。。

所以从来没听过时差吗

@justrand 不是完全固定分配的，但是票放出来那一瞬间不会是动态的，比如在发车前一天或者前几天，会慢慢把区间票再放出来。你真正去买下票就知道，始发站 ->终点站的票是最多的

我这有个现成的例子，你可以现在去搜 1 月 16 号 G33 这趟车，这个车北京发车经过鹰潭，终点站是南昌。

你会发现可以买北京->南昌的票而北京->鹰潭却是无票的

@badcode 我买票一致都是多花钱直接买到终点站，甚至都不用抢，慢悠悠的买就可以，我家那一站貌似就只有一两张票，刚出来就没了

并发量不高，错峰抢票

而你觉得线路上这么多站要加锁很复杂，其实并不是，每个站的票都是预先设定好的

假设沿线 A, B, C 三个站，现实是会分给 A -> C 10 张票，A -> B 5 张票，A -> B 这个买完后就算 A -> C 可以继续也买不到 A -> B 的，虽然实际上这么乘车是没问题的

很多付费的梯子都是有专线的

影响摸鱼

(又到了推荐租自如的时候了

操作系统也要干活，而且 redis 也有不少后台线程。

条款写的不够明显 /太复杂 /太长导致消费者没看谁的错呢？