1. 即使正确执行预期输出应该是 101
2. 这里应该关注 += 操作是否是原子的
3. System.out.println 的调用时机在此处并不保证在所有 Thread 都完成之后

从 tcp socket 上来看的话，双栈 socket 是很常见的吧，
简单举个 C#的例子，
var listener = new TcpListener(IPAddress.IPv6Any, Constant.TcpPort);
listener.Server.SetSocketOption(SocketOptionLevel.IPv6, SocketOptionName.IPv6Only, false);
这样这个 tcp listener 就可以在同一个端口同时监听 v4 和 v6 的流量，v4 的地址会被加上 ffff:前缀变成兼容 v6 的

https://www.google.com/appsstatus#hl=zh&v=status

活久见，所有主要服务都挂了

同等
今年下半年刷 MacRumors 已经已经无喜无悲了
从最开始爆料 11 月份，到爆料 12 月份，到最后目前看下来是 1 月或者 2 月陪跑 A 卡 6000 系
工作原因有一些软件强依赖 intel 系统，又频繁搬家，现阶段 16 寸是唯一的选择

先不提数组的实现，
在评审中遇到手写基本数据结构的，不限于链表这种
一般我都会建议提交者详细阐述一下这里的需求以及为什么标准库自带数据结构在此处不能胜任，以及是否有良好的开源库的实现等
说实话以上足以排除 99%的情况，工作这么久了还真没遇到需要手写基本数据结构的。

哦补充下，如果根据 UUID 获取识别结果有可能是等待中（ PENDING ）的话，那只能走第二种方案添加一个定时轮询了。

个人感觉有两种方案，
第一种是
async.gather(所有上传图片请求)
async.gather(所有图像识别请求)
async.gather(所有图像删除请求)
适合图片上传时间差别不大，服务端能存下这么多图片，以及图片识别时间差别不大的情况

第二种是定义一个函数
async job(image):
await 上传图片
await 图像识别
await 图像删除

然后 async.gather(所有的 job)
我的话应该会选择第二种吧，总体的执行时间理论上是一样的

也遇到了同样的问题，
之前的解决办法是开关屏幕，多谢分享解决方案，回家试试看

1.是的
如果盒盖的话就只有 egpu 运行，如果开盖的话 dgpu 只负责内屏部分的显示，所以非常凉快
2. 如果不玩游戏的话去淘宝靠谱的店买 RX580 就可以，记住国内特供版本的 RX580 需要折腾一番还有几率不能运行，记住选择正确的版本。2304 流处理器版本的
3. 这个有很多选择。https://egpu.io/best-egpu-buyers-guide/ 可以参考这个网站购买

可能每个人感受不同吧，我不想仅仅是为了餐补和打车费就耗在公司里。毕竟正常下班的话我可以完全安排自己的时间。
我理解的有意义加班更多还是在项目排期确定的情况下有“盼头”的加班，而不是说领头人自己都不知道要做什么来回内耗式的加班。

单说第二部关于 HTTP 状态码的。

如何判断正常的情况，看你的行文中的意思是正常情况还涵盖了发生业务错误的情况？那请问以下几种常见的业务错误情况应该如何考虑，难道是返回值给 200，然后维护一个错误详情的字段？

- 前端在一个本该是 utc 格式的日期字段中传了一个不受支持的日期格式
- 前端给一个不该空的字段中传了一个空值
- 前端传了一个不存在的用户 ID 导致后端处理请求时丢了一个异常
此处又分两种情况 1.异常被成功捕获 2.异常没有被捕获
- 前端传了一个非法的用户 token

另外很好奇，运维如何能在业务不正常的时候影响到 HTTP 的状态码。

换汤不换药的推荐 withlatestfrom, 不过这个操作符分主次，根据你要的逻辑写就好了

@1490213 我明白你的担忧。仔细看源码，nexttick 维护了一个需要执行回调的队列，在合适得时候通过一个循环同步的执行。

所以第一种情况 A 先加入队列，然后 B 加入队列，在合适的时候执行了 A，此时浏览器根本没有空调用 await 之后的逻辑先执行了 B，然后才有空调用 await 之后的逻辑

第二种情况就比较简单了，你可以试着分析看。await 所带来的 async context （等价为 promise resolve)为什么会先于 next tick （也可以等价为 promise resolve)执行

对上条回复的补充，如果你配置了 tslint，你在 await 那一行会收到警告

'await' has no effect on the type of this expression. ts(80007)

这里 no effect 并不完全正确，因为他的确会存在潜在的执行顺序变化

对以上两个回答都不敢沟通，给题主一个简单的测试环境
async function test() {
let cb = () => {
Promise.resolve().then(() => console.log('awaited'));
};

await cb();
console.log('after await');
}

test();

以上代码加不加 await 对运行结果是有差异的，分别为，
添加 await：awaited，after await
不添加 await：after await，awaited

究其原因是因为当你给一个 function 添加 async 关键字并在其中使用 await 之后，此处就会产生一个 asynchrony context，所以以上代码最后可以理解为以下的等价代码（仅供参考执行顺序，并不完全严谨）
Promise.resolve()
.then(() => {
let cb = () => {
Promise.resolve().then(() => console.log('awaited'));
};

cb();
})
.then(() => console.log('after await'));

所以题主的理解“ await 后面跟一个函数执行(没有返回 Promise 以及没有 then 属性), 应该是直接返回值, 语义上不应该对执行顺序产生影响”并不完全正确