头条没有 Java 开发岗位
至于十点下班，大概是最早的吧....
如果可以，都实习几天就知道了

thread 已经是 deprecated 了
推荐的做法是，创建一个继承自 threading.Thread 的类的实例 obj.（需要实现 run()函数）
然后 obj.setDaemon(True); obj.start();
while threading.active() > 0:
pass
保证主进程不退出，后台线程得以正确运行

@cqcn1991 这说不好...先投呗，反正也不少块肉

@ETiV 一个 9.3.x 还是 9.2.x 的 4S，那会不是刚 5s 的越狱出来，只有 64 位版本的，要是能操作，就让家里人给寄过来，刷个 iOS6 还能流畅一把，怀个旧啥的

有 4S 降级成功的么？有的话我马上跟着来一发

手动处理下 signal

1. 合并的时候手动解决冲突
2. 一个人回滚，基于另一个人的提交再来一次。

不太明白什么叫对 commit 的修改。

是你们基于同一个分支都做了 commit --amend 么？

不管什么情况，一个人先在本地把 commit 做成期望的样子，提交一个新的分支。另一个 fetch 这个分支之后，rebase 到自己的分支上。保留两个人的操作。

[git 教程]( https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/)

一般来说，要么 push 要么 pull。
根据业务需要权衡是轮训还是长链接。
至于具体能支持多少 QPS，跟如何实现、业务复杂性都有关系，建议自行压测。

一般而言，除非实时性要求极高（ IM ）和特定必须推送的业务。端上都会采用 pull 的方式进行沟通，这种配置信息变动，其实可以封装一个加载配置的工具库，各个业务逻辑中调用这个工具库，就做到配置信息 lazy load，加上一定时间的缓存。这样对端上而言，配置的加载也是 lazy load。