建议京东，方向选择要慎重。

17 款用了快三年，因为电池鼓包，前不久免费给换了电池+C 面。

客户端一般会缓存服务端的列表，只是服务提供方列表变动没法通知到客户端了，rpc 调用没啥影响，新服务提供方上线没法使用，下线依赖客户端自己调用失败后才能发现。

北京

可能不会

不会，应用层调用了写入，操作系统并不少马上就写磁盘，有 pagecache 。

while (a == 0) {
long x = b; // 为什么这里读 b, 能让线程同时读到 a 的最新值? 如果注释这行, a 就读不到
}
没有 long x = b; 这行的话，jvm 会优化这几句代码，可能根本就不执行这个死循环。

while (a == 0) {
long x = b; // 为什么这里读 b, 能让线程同时读到 a 的最新值? 如果注释这行, a 就读不到
}

有英语面试不？

@lynan 大厂一般不会在半夜发布的，半夜发布出问题了，如果解决问题有可能很多人不在比较麻烦，所以都选择在白天发布，你说的半夜遇到超时问题，可能是压测导致的，压测一般下半夜开始。

大厂机器都很多，负载均衡机器加上探测应用机器是不是活的这种功能，就能解决发布时不影响功能的问题了。

可以利用桶排序，记录每个分数段的用户数量，根据当前用户的分数能直接算出大概排名。
最高分数段的用户特殊处理，可以计算他们的准确排序。
用户好友数一般不多，直接排就好了，可以把好友的分数缓存到当前用户里并且不用实时更新，只需要实时更新自己的分数就行了。
如果分数跨度不大的话，假设分数只有 0 到 1000 这种，直接记录每个分数有多少用户，这种情况可以 O(1)算出每个人的准确排名。

@feiniu “说你可能当个小 leader” 说明你有可能成为那个公司技术最好的人，这种情况还是算了吧。

上海有不？

杭州的户口就不用操心了，基本没啥门槛，也没啥用。把握这次机会搞个上海户口吧。

@cco 我身边基本都是前转后的，包括我自己。

1 、生成订单号
2 、预扣商品库存
3 、订单生成
4 、真的扣库存

订单服务提供反查功能，根据订单号查是否成功

各种状况：
1 和 2 失败没任何影响；
3 那步挂了，库存服务过段时间反查订单是否成功，没成功的话将库存恢复；
4 那步挂了，库存服务过段时间反查订单是否成功，成功的话变成真的扣库存。

成功从客户端转成了 Java

现在支持现场面试不？

@shadowyue
@xuanbg
app 可以 cookie 啊，发请求的时候在 header 里带上去就好了，跟 web 没啥区别。