@julyclyde #34 别说 python 了，你用 c 或者汇编写一个这个不如果特别指定用原子操作指令的话也很大可能不为 0 ，你不会想说 cpu 也有 bug 吧

其实就是 3.10 开始除了 JMP 相关字节码指令和 CALL 相关字节码指令，其它的字节码指令都不会再触发 GIL 调度切换线程，所以不止+=是原子操作，a = b + c * d / e 这种一行多个计算操作复杂一些的也是原子操作了

JMP 指令和 CALL 指令用的实在是太频繁了，比如 for range 就会同时用到这两个指令，所以影响不大，性能可能略微提升了那么一丢丢

@doveshelly #7 http long polling 就是用于服务端主动给前端应用推送消息的，流程显示二维码的时候请求一个后端接口，但是这个接口不立刻返回，而且等着另外一个用户扫码之后请求已扫描接口请求来触发这个接口的返回，所以这个也是实时的，之所以这个流程依然是无状态的，是因为服务端会缓存已扫码状态一小段时间，所以无所谓先扫码还是先请求 http long polling ，而且如果请求 http long polling 超时就再次重试就行，知道关闭二维码页面，实现起来也简单，和轮询实现逻辑差不多，但是再次重试不延时所以是实时的

其实 websocket 状态管理确实挺复杂的，你这个需要展码前就完成 websocket 建立吧，安全性加 TLS 就行但是服务端还是要用 token 做下校验

其实这种短时通知其实用 http long polling 更方便，可重入实时性也有保证，展码和 http long polling 请求无关前后，spring boot 可以用 DeferredResult 就可以在等待期间释放工作线程了，其它框架估计也有类似支持，如果有多节点的话可以考虑这种

https://gist.github.com/snower/f8ef25e57c72f9b41fb31ee8b164193b

http long polling 的好处就是依然是无状态的，实现和维护都简单，而实时性和 websocket 一样

验证不通过其实就是输入错误难道不是 error 不应该走 error handling 么？谈 try catch 会增加性能开销那更是扯淡，不是说没有性能开销而是实际业务中纠结这个毫无意义

想多了，蜂窝网和宽带网组网过程就不是一样的，比如手机在基站间切换是不断网的吧，而且似乎相同基站和相同子网的蜂窝网并不能互通吧

更无语的是哪种不能说不熟，发个在吗，回了在，过半小时他又给你发了个在吗，然后就这么来来回回的折腾，感觉血压都升高了

@xiaocongcong 这种难道不是应该说，你好，现在是否有空，云云之类的，在吗这个其实更不礼貌了有没有😂😂

不 join 单表读有啥压力。。别过度优化啊，复杂查询大多也能接受延时，还是异步同步好吧

@vislins 矫情，迫害妄想症，好像苹果谷歌就不限区似的，没件事情都是有成本的，都是要考虑成本的，只有成本没有收益的事情谁愿意干啊，不影响他人谁 TM 想理你

工信部发的是政策要求，其实并没有任何技术实现要求，也不可能有技术实现要求，实现是各厂商自己怎么选择的事情，最终落实估计也就是不备案的不允许上应用商店的事情，这早 8 年的不就已经是这个样子了，一个事实标准变成一个政策要求，搞不懂大家为这事激动个啥

https://mp.weixin.qq.com/s?__biz=MzIyNDU2NTc5Mw==&mid=2247510019&idx=1&sn=5a79379d068139523fbd346402cae893&chksm=e80fe74ddf786e5bcaf73ba2194bc11889a33a544ed12c650be7d177472417b423c7ffbd5524&from=industrynews&version=4.1.8.6020&platform=win#rd

人家刚还发了文章详细介绍了怎么优化内存的

长期的话边际收益太低，工资涨 3 倍估计才能覆盖边际成本吧，但是对于公司来说，增加两天工作日产出增加估计都不到 20%，所以显然员工和公司都不合算，所以不接受，也没啥意义

高带宽内存，现在大火的，AI 也很需要

把常用的不需要代理的应用比如微信支付宝什么选按应用分流，其它的不怎么用其实就不怎么耗电了，按应用分流是安卓系统提供的功能，底层走的是策略路由表，所以性能和能耗是可以得到保证的，不用担心太耗电

304 不是未修改可以用缓存。然后浏览器就读缓存成功了，最后给你返回 200 没问题啊，毕竟已经有正确的内容了，是你理解的有问题吧

如果只是某中 pod 简单用下，倒是弄个 pod 配置里添加下 hosts 把需要出口的域名指向需要出口的地址，然后在需要出口的地址挂个端口转发程序 pod 就好了，如果有出口 node 端口占用的问题，那么还可以把 hosts 指向本机然后在当前 pod 再配置个容器再端口转发一次，这样出口 node 节点就可以使用其它端口了

当然如果大部分 pod 和大部分流量都需要转发那还是 route+nat 或是 istio egress 比较好

哥啊滴滴被罚已经是很久以前的事了，你这延迟有点高了，再说大佬都说过知错就改还是好同志，而且吧红绿灯倒计时也不是啥敏感数据，有啥不能开放的，也确实是个好事也可以为未来智驾做铺垫，管方确实在开放接口了