@amiwrong123
这里我怀疑原因是这样：这个 contravariant 类型 <? super T> 对于使用 Comparator 的情形是有意义的，例如有 type B, D 并且 D extends B，PriorityBlockingQueue<D>可以使用 Comparator<D>，但是也可以使用 Comparator<B>，因此一般这种情况会允许 Comparator<? super T>。
但 Comparable 是 obj.comparesTo(other)，这里用 contravariant 类型没有意义，因为类型擦除，运行时毫无区别，大概只是实习生照着 Comparator 分支抄过来的……

很好，迈出了走向 Scala 的第一步 [并没有]

@pierswu 这个是最精确的

哇，非常好的问题。先尝试回答第 2 个:

PriorityBlockingQueue<E>的类型参数 E 本身没有类型约束(例如 E extends Comparable<E>)，因此在 PriorityBlockingQueue 的实现内部，要插入或删除一个 E 类型的元素时，是通过先把元素强转成接口类型 Comparable<? super E>，再进行比较，再赋值给对应的位置 queue[???]。例如

private static <T> void siftUpComparable(int k, T x, Object[] array) {
Comparable<? super T> key = (Comparable<? super T>) x;
while (k > 0) {
int parent = (k - 1) >>> 1;
Object e = array[parent];
if (key.compareTo((T) e) >= 0)
break;
array[k] = e;
k = parent;
}
array[k] = key;
}

这里的问题是，如果 queue 不是在构造函数里初始化成 Object[]类型，而是 E[]类型，上面的 array[k] = key 将会导致 ArrayStoreException 。例如，如果 E 是 Integer，cast 成 Comparable 没问题，但 Comparable 不是 Integer，没法存回 Integer[]。所以 queue 需要初始化成什么都能存的 Object[]。

但其实还有更简单的办法——把 array[k]=key 改成 array[k] = x，queue 就可以安安全全的使用 E[] type，也不需要那么多强制转型。至于为什么 Java 没这么做，就不是我能回答的了。

至于 PriorityBlockingQueue<E>为什么不直接声明成 PriorityBlockingQueue<E extends Comparable<E>>，是因为 PriorityBlockingQueue 同时支持 Comparable 和 Comparator 两种比较接口，插入删除都是两种版本，E 的类型约束都是靠运行时强制转型的动态检查，没法静态声明。

@lxk11153 我还是要重复，http 1.0/1.1 与是否 HTTPS 没有关系...在 HTTPS 里跑的可以是 1.0 也可以是 1.1 。说白了 1.1 主要的区别只是可以重用连接，所以你看到的客户端大多默认发 1.1 请求。你用 curl 是可以指定发 1.0 请求的。

@lxk11153 是的，我的回答 #10 就是在说，HTTP 是 HTTP over TCP，HTTPS 是 HTTP over TLS，和 1.0/1.1/2.0 无关。但 2.0 规定必须是 over TLS 。代理是另外一种例外情况。

@lxk11153

方案 1: 一台电脑 500 线程 ，无代理 ，请求同一个 http 接口，（可能需要考虑 http 连接池
方案 2: 一台电脑 500 线程 ，每个线程一个不重复代理 ，请求同一个 http 接口（假设代理质量优

不看线路连接质量的话，当然是 1 快，2 是完全额外的开销。但直连丢包率高的话走代理就有优势了，就是相当于改个路由。

@lxk11153 不是，本来 1.0/1.1/2 只是 HTTP 应用层协议，由下面传输层决定是 HTTP 还是 HTTPS (TCP 或 TLS)。复杂的地方在于 HTTP 2 强制要求 TLS，而 HTTP 代理又允许在先走明文 TCP 建立连接，再走 CONNECT 原语在 HTTP 层把连接升级成 HTTPS [大型狗头]

换句话说，低丢包率的环境(这里说的低是非常低，低于 1%那种)，socks 表现会好一些，反之 HTTP 代理会好些。当然，如果可以配置，你也可以让 socks 代理禁用多路复用。

很难说，要看你实际用的场景。理论上说 Socks 可以单 TCP 连接复用，在里面跑多个连接，能省下从客户端到代理这一段多次建立连接的开销。
有点类似于 HTTP 1.1 长连接，单次连接可以跑多个 HTTP 请求，省下建立多个连接的三次握手开销。区别是 socks 省的连接建立开销只是客户端到代理这一段；而支持 HTTP 1.1 的代理在两端都只需要一个连接，但只限同一个远端 server(不是代理 server)，不同的 server 还是不同的代理连接。
然而更复杂的情况还有在 socks 里建立 HTTP 1.1 连接，以及 HTTPS / HTTP 2.0 。Socks 在传输层，不管 HTTP 版本，所以哪种 HTTP 都能跑，都能多路复用。HTTP 代理在代 HTTPS 的时候必须走 HTTP CONNECT 建单独的 tunnel，并且 HTTP 2 因为强制 server 端证书，其实不能走 HTTP 代理的。更精确的说，你可以有一个跑 HTTP 2 的协议的 HTTP 代理来获取 HTTP 1.0/1.1+HTTPS 的网站，但无论何种 forward 类型的代理都不能代理 HTTP 2 协议的服务器。只有反代可以代理 HTTP 2 服务，因为反代可以正确配置证书。

说了一堆，你可能觉得 Socks 代理会更快，但其实未必。多路复用一个 TCP 连接看上去很美好，这也是 Google 当年设计 SPDY 的动机，但实际应用，只要跑在这个单连接里的任意一路 channel 有数据包堵塞，你所有 channel 就全堵塞。

打个比方，你走 socks 代理复用一个 TCP 建立了 5 个代理连接，走 HTTP 代理用 5 个 TCP 连接建立了 5 个代理连接，如果这 5 个连接里有一个出现丢包，你走 socks 的其他 4 个都得一起等着，而走 HTTP 的另外 4 个还能正常收数据。

所以说完了都是废话，请实际试试看吧 xD

java 有 try with resource, 为什么 defer?

@shiroikuma Scala 啥时候宣称过是惰性求值了。你要 Lazy 的话自己包个 lazy view:

立即求值
scala> List(1,2,3).map(_*2).take(2)
val res18: List[Int] = List(2, 4)

Lazy
scala> List(1,2,3).view.map(_*2).take(2)
val res16: scala.collection.SeqView[Int] = SeqView(<not computed>)

Lazy+执行
scala> List(1,2,3).view.map(_*2).take(2).toSeq
val res17: Seq[Int] = List(2, 4)

@gantleman
我回复你上一条是以为你真的想了解自己的代码糟糕在哪里，结果看来并不是。

我翻译一下我上面的回答和你的答复：
我：这是个基本的常识。基，本，的，常，识。
你：我自己的代码，爱怎么写就怎么写。

那我也不用那么客气了。我 1995 年开始写 C，从底层一路写上来，你还没听说过线程的时候我就在写线程调度器了。没见过写成这样还这么理直气壮的，“过度的防御编程并不能解决这个问题”。早拉黑得了，浪费自己生命。

@gantleman C 程序员需要特别小心内存越界。你的 pEvent 只在栈上分配了 4 字节(32 位)或 8 字节(64 位)的空间，然而你的 memcpy 对传进来的 valueLen 不加任何检查，调用者轻易就可以用自己构造的数据覆盖栈上不属于 pEvent 的空间。这是个很基础的问题，随手搜一下有很多文章，例如 https://www.jianshu.com/p/47d484b9227e

看了一下官方示例 https://github.com/surparallel/pelagia/blob/master/src/psimple.c
只能说，这不像是写了十几年 C 啊：


static int TaskRouting(char* value, short valueLen) {
void* pEvent;
memcpy(&pEvent, value, valueLen);

这 memcpy 心够大的……

Uber 员工表示，嘿嘿嘿

你都是机械硬盘，本来应该是放不同硬盘导入更快。

但既然现在已经在一块硬盘上，就不要再倒腾了。可以大致想象成 0.8+1.0 > 1.2

@onanying 所以综合你之前无数据库的 benchmark 结果，总的推论是 php 的 MySQL 驱动或者连接池性能要比 go 的差不少。

你这个 benchmark 看起来 cpu 主要花在 json 序列化上，php 的 json_encode 是 C 写的，按理说不应该差这么多。

我怀疑数据库连接池的行为或者数据库驱动有什么不同，建议拿掉 json 序列化再测一下。