并不看好 zend api 的二次封装，熟悉 C 的，模仿 php 源码 ext 目录里的写法就能开干了，常见的跟 php interop 的姿势全都有。写扩展的人本来就少，其中绝大部分都用的 php 官方那套，选择一个二次封装的方式，无异于把潜在 contributor 排除在外。

前几天把 php 同事写的 Java 基础库重新实现了一遍，只用了不到 1/3 的代码，在他们经验里，估计开发效率能差 5 倍以上了

因为总有 sb 能写出内存泄露的代码来还对此毫无意识，不问能行吗？

不用懂 gc 细节，只要熟悉对象生存周期内在内存中的流动，看得懂 gclog，会调几个参数就够了

JVM789 的 GC 变化不大，不大用的 serial，默认的 parallel，并发的 CMS 和 G1(JVM9 默认 G1)，CMS 已经 deprecated。所以只需要了解 parallel 和 g1 了。

JMM 变化更小，核心的东西从 Java 5 开始没有变过，到 Java 9 也不过细节上稍有增强，当然了，JMM 跟 gc 没什么关系。

@jjianwen68 再过一年，oracle 官网下载不到 java 8 了，不想用 openjdk 的，提前下载做好备份吧

@ZSeptember 开源库考虑兼容性一般用 6 导出 lib，但是项目自身并不需要用 6。阿里定制版 JVM，2010 年是基于 openjdk6，2011 年的时候是 7，2015 年开始基于 openjdk8 做的定制。大厂很多老项目不一定很快迁移，但是新项目用上新版本也没那么慢。

@ZSeptember 大厂 Java 8 也不少了，哪家大厂都在用 6?

@onanying
https://docs.phalconphp.com/en/latest/db-layer#connecting-to-databases
https://github.com/phalcon/cphalcon/blob/master/phalcon/db/adapter/pdo.zep

Phalcon 本身没有长连接，但 PDO 有，建议还是测试一下有无长连接时的性能差距

难道你们都用的发行版默认的 python?

@aristotll
@vjnjc
技术上都可以移植，测试+修改 几轮迭代下来，迁移到 8 都不是问题。问题是成本，迁移的付出，有没有更高的收益，不兼容的地方修复成本高不高，迁移到一半搞不定是不是宣布迁移失败。所以这种老系统，一般能不动都会尽量不动，成了没有功劳，败了就是污点。

@hubert3 还有很多 1.5 和 1.6 的，而且没法迁移的那种

Phalcon 数据库开长连接了吗?

6 个月足够从零开始学一门新语言了

@gouchaoer 不是，我是 Java 写 log，8K 的 buffer 同步写入严重影响性能，另外开个写 log 专用的线程就解决了，多线程就这点好，队列里面扔什么都行

阻塞 IO 是很慢的，前几天压测一个简单的应用，不记 access log，单机 QPS 可以达到 20 万，一写 log 就掉到 10 万以内，只好开了个生产消费队列，用一个独立的线程专门写 log。

@Kilerd 开多进程没用，用多个帐号跑也没用，cgroup 是按 group 限制的，一个 group 内所有用户的所有进程都受控

@lrxiao 不是 python 的限制，是内核 cgroup 的限制，像 Ubuntu 一般默认 1 万出头，跟 stacksize 无关

@NoAnyLove 16G 内存正常上限大概是 12 万线程，楼主的测试远远没到硬件限制

@jingniao
UserTasksMax=
Sets the maximum number of OS tasks each user may run concurrently. This controls the TasksMax= setting of
the per-user slice unit, see systemd.resource-control(5) for details. If assigned the special value
"infinity", no tasks limit is applied. Defaults to 33%, which equals 10813 with the kernel's defaults on
the host, but might be smaller in OS containers.

limits 限制排除了的话，显然是 cgroup 的限制，检查 pids.max

@gouchaoer 这倒是一个因素，我司重构到 cli 的时候，遇到过几次常驻内存引起的问题，老代码根本没考虑过单例会跨请求