请教 Java 的 Quasar 库的 Fiber 性能问题及使用姿势

Question

今天试了下 java 的 fiber 库 quasar，有些疑问

测试方法是 扫描本地端口 8000~9000 查看端口是否 socket 监听，本地启动了一个 8080 的服务。比较不同方式扫描一遍1000个端口耗时。

quasar 的耗时 在 800ms 左右（方法 for 循环 fiber）

多线程的耗时（单位毫秒）

    // 3 thread
    // time elapse: 5557

    // 5 thread
    // time elapse: 5635

    // 10 thread
    // time elapse: 5336

    // 20 thread
    // time elapse: 3606

    // 30 thread
    // time elapse: 3495

    // 40 thread
    // time elapse: 2804

    // 50 thread
    // time elapse: 2309

    // 60 thread
    // time elapse: 1994

    // 70 thread
    // time elapse: 1661

    // 80 thread
    // time elapse: 1580

    // 200 thread
    // time elapse: 942

    // 500 thread
    // time elapse: 517

    // 1000 thread
    // time elapse: 434

感觉没有碾压式的优势 虽然多线程的线程数创建的很夸张。。。
但是看其他人的比较，fiber 应该是碾压式优势的 特别是这种 block 场景

另外多线程版本用的是 java.net.socket 的 connect 方法连接端口，这底层实现是个 native method (AbstractPlainSocketImpl.socketConnect) 。

测试如果使用 fiber 调用此方法 connect 的话 耗时是在 3400 左右，也就是 quasar 的 fiber 应该是无法代理此方法的，而是需要使用 FiberSocketChannel 来 connect，也就是说明 quasar 并不是无缝接入的，还是需要代码改造的

有过 quasar fiber 的使用经验么 可以解释下我这个结论是正确的 还是我操作方法有啥问题

Answer 1

自问自答来了。
着实自己有点蠢，测试的样本不够。

后续测试：

扫描一万个端口
200个线程是 8914ms
一万个 fiber 是 2466ms

扫描五万个端口
200个线程是 45173ms
一万个 fiber 是 3074ms

可以说 fiber 在扫描的数量提升之后，性能是远远超过线程池的方式的。

不过，前提是使用改造的 FiberSocketChannel，如果使用的是和线程池方案相同的 java.net.socket （AbstractPlainSocketImpl.socketConnect）实现，反而速度严重变慢，远超线程池的时间。可以说，fiber 的使用条件就是不要阻塞住 fiber 任务本身。