用 puppeteer 直接运行 chrome 爬..

@yema50 Wrapper 统一放到响应 Service 里. 不要用到的地方到处写..

高血压还敢强制喊打.... 不要命了属于是.

@wqhui sql 有 r2dbc 规范, 很多数据库都支持貌似.

安卓旗舰也会卡...

不一定吧.. 你看 java 实现的 mq, 写入有用 mmap 的, 也有用 FileChannel write 的. fileChannel 这种批量 write 性能不一定比 mmap 差.. 看场景.

可以参考 https://www.jianshu.com/p/d0b4ac90dbcb

@lesismal 虽然 go 的 内置协程支持, native 编译这些的确是优点, 但缺点依然不少. 我工作用 java, 不过也是在不断的学 go..

@lesismal 事情不是非 1 即 0, 非黑即白, 不要太偏执,

java 里 gc 可选择的很多, 低暂停的 gc 做的比 go 的 gc 好的也有很多. zgc, Shenandoah, 商业的 zing 等.

java 内存这块其实和 go 相差无几, 只是现在开发比如套上一层 spring. 框架占的内存是大头, 但是这类框架抽象成都高, 很好用, 能简化开发.. 所以大家依然愿意用. java 和 go 裸写内存占用区别真的不大..

java 里查数据库不一定要用 jdbc, 比如 vertx 里就是自己封装的. 还有 r2dbc 这种, 数据库官方都在支持..

不过没有语言级别的支持.

只是用 reactor 或者回调的化还是不够友好.

java 并发编程实战这个书可以, 不过我也没看完, 因为很多通过 blog 都学了


JVM 就周志明写的书<深入理解 Java 虚拟机 2>就挺好的.

asyncio 不能降低你代码里单个 query 方法的耗时, 他要做的是用少量线程就能支撑超高的并发量,, 这个用线程是很难实现的, 单个请求的响应时间并不会变得更快,

gather 不是顺序执行, 都 asyncio 了, 只要里面 task 不阻塞, 就是异步执行的.

你这个没啥问题, 根据你加大到 1000 次, 差距挺大的, 所以应该是量不够大.

一个接口不可能这么高, 但是其他的接口也有网络 io, 和你测一个接口 1000 次概念差不多, 并发上去了, asyncio 性能差异就出来了..

如果只是一个接口, 没啥访问, 直接同步搞.. 简单

次数调大点试试. 看起来没啥问题. 可以把代码贴完整点, 包括 loop.run_until_complete()这一块

刚好你这个 task 里也是 5 个 sql 的 await.. :(

sorry, 理解错了.. 光看了你问题里写的 5 个 sql, 我漏看了下面的 gather, 你要问的是 gather 里的这 5 个 task 吧

nodejs 继续执行后面是因为你不用 await nodejs 的这个 promise, 而是等他返回结果返回后, 调用你注册的回调 function.去处理 function 果返回

nodejs 里, 如果你后续的执行依赖某个 nodejs 异步函数的结果, 那不还是得等异步函数结束拿到结果后再执行后面的结果吗.


1:
var s = asyncFunc(xxx, function (res) {
res 是这个函数的返回值.
}); // 不需要等待 asyncFunc 返回值,

xxx(); //


2:
var res = await asyncFunc(xxx); // 需要等待 asyncFunc 返回值
console.log(res)
xxx()

类似这两种方式.

你这代码逻辑上还是`同步`的, 因为你有 await, 会等待每个 sql 执行完成, 就是说一个 sql 执行完后才会去执行下一步的 sql. 只是你这个 sql 还没执行完的过程中, 线程不会卡在这里,, 而是会去执行其他的异步 task. 等你 await 的 task 返回后再继续执行你这个 task.

异步不是你理解的这样的异步. asyncio 的好处是异步 io 的并发..