右边是基于 NMT 出的么？为啥我感觉还少了一些的？

用 pmap 和 gdb dump 再深入看看？

一般都是连接泄露
lsof -n -P > result.txt
然后拿下来看。

如果超大量 CLOSE_WAIT ，要考虑内部存在的服务请求等网络请求、在超时设定上的合理性。内层网络调用超时应小于外层网络调用超时，并逐层保证。如果使用 netty 等非线程池、使用事件 LOOP 处理的，更会容易触发此种情况。

同时，可以通过 jstack 等做个 threaddump 分析，有可能快速定位问题程序栈位置。

LZ 得讲清楚限制并发的限制在哪里？
A 、B 现在有各多少能力，限制资源在 B 还是在 A 内的其他部分。交易场景可异步化程度如何。

如果只是构造 token ，假设你 token 需要 GUID 类似的全局唯一控制，那么 A 本身的生成 token 动作基本不应该受什么并发限制。如果 A 构造了 token 之后，A 还向 redis 等设施缓存，那么问题就变成 A->redis 的并发能力有多少。如果 redis 并发能力不够，是否要 redis 自身集群化；或按其他交易标识等信息 hash 化之后，分交易集群分别独立处理链条的方式。

如果 B 有并发能力限制，那么还要问 A->B 的请求是必须同步等待返回的，还是可以异步的；又还要问，A 是否可以对用户异步，是否可队列化请求，异步返回等等。

LZ 需求题干给的信息偏少，建议思路会很发散的。

当然如果胆大，直接在电池上戳好洞，就这么用下去，感觉也不是不行

长期充电会电池鼓包，需要淘宝找人改个无电池电源子板直接启动（ 50~150 左右的价格）
然后装块散热铝底座，就可以长期用了

我来咬勾

Namenode 当文件数多的时候，还仰仗 JVM 的堆内存管理，其实挺有问题的。fullgc 一下就整体不服务。

有没有 namenode 的非 java 的实现呢？

@shuimugan 难点在于，设计的是监测系统，而不是被监测系统。不能因为要上个监测系统，存量的被监测系统就要做一个新的非线程、异步化的方式来处理。这种思路是不太能解决问题的。

考虑考虑如何提升这些系统的非功能性，功能性水平总会依赖需求；

但非功能性需求程序员自己就可以去考虑、而且很提高设计水平。

如：高可用性、性能效率、监控、自恢复、可扩展性、可面向二级用户的解耦快速研发（解耦为底层研发和上层二级用户业务逻辑研发）

这些上面自己想想现在公司里做到了什么水平，如果交给你来做会有什么的设计、框架，用什么样子技术，能够什么水平？如何考虑成本产出？

做一些不太大的项目的 port 呗，类似只有 c 代码的 port 到 java ，只有 java 的 port 到 javascript 等等
参与下开源，挺好的

我 realvnc 用了都 10 年了，没啥问题

另外补一句，大有界循环可以用-XX:+UseCountedLoopSafepoints 参数之后拆解。

楼上说的 arthas 火焰图搞一把呗
不具备条件部署 arthas 条件的，也可以先用的简单的 jstack 打几个线程 dump 看看线程大都在跑什么，但若存在大有界循环之类的长时间不进 safepoint 情况，线程 dump 会不准

所以我不买 CDN ，也会先申请一个私有固有域名，后面接 304 跳转，然后到对应的 raw 或者其他存储或者 CDN
保证这个私有固有域名肯定在手里面把控住
后面随便哪个 raw/存储/CDN 挂掉，都可以用域名 304 跳转的改动，再来做分别的对接

差不多 11 年开发，7 年技术管理了吧，基本翻倍稍不到点

现在没事还自己稍微写点 JVM 相关的东西

throw 真正的意义是消息传递，return null 是函数返回
为啥会对等起来比呢…

@Maxwell7 这种小风扇产品能不能撑住 7x24 小时运行，我一直有点疑问。有压力地长开机、风扇和散热撑得住吗？

@Maxwell7 有点道理，还真都差不多

@Aumujun hadoop 那套是指 mr 找 datanode 那一套？但很多的场景其实也不是这么复杂的大数据处理场景。只是类似需要一个分布式系统里面，找个节点去执行个和第三方 api 做个连接，取一些业务参数更新到本地数据库之类的事情。很简单的任务，但要保证高可用和超时失败重做等要求。

altstore 我都用了快 3 年了，sidestore 有什么新优势么？