@house600 细节上，做了多个线程池的梯度下降处理，举个例子，定义线程池 poo1 -> pool2 -> pool3 ，最大线程数量从高往低，每个 namespace 定义的最大 pool 占用百分比，分别是 5%，20%，30%，类似这样，一个 namespace 最大占用线程数：
max = poo1*5% + pool2*20% + pool3*30%

除非同时有 20 个 namespace 都占用了那么 5%（那你系统一定有大问题），否则资源最大化同时，又有隔离限制，达到一个平衡

@lesismal 我知道，你实现了一个 nio ，替代标准库，不过我的观点不在此，我的意思是，真实的业务，在这个网络层面之前，其他已经挂了，还没到这里，问题终究就是需要对资源进行限制

@cubecube 是，我赞成协程不需要池化和复用，只需要控制顶层资源


@house600 这里是这样做的：
executor.execute("processNamespace", () -> handle***(xxx), Opt.withMaxConcurrent(100));
的时候，把 runner 包装一下，执行方法前 processNamespace +1 ，之后 processNamespace -1 ，
通过一个阻塞的变量控制： https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html
计数器控制：
https://stackoverflow.com/questions/69760046/java-conditions-with-locks

比如你设置了最多 10 线程，那么当前 10 线程可以，再 +1 = 11 的时候，就会触发等待，需要计数器 -1 才可以继续

@dqzcwxb 你说的都是 *理论上*，好像我们现实中没遇到这场景一样，还是 Go 的服务，够原生协程了吧
现实就是：几十万的协程，就把服务快击垮了，cpu 99% 以上，响应不过来，总有其他短板阿

你要是写一个 hello world ，确实可以不用考虑

@TWorldIsNButThis 是啊，我只是针对上面一个发言，就是协程不是万能的，并发控制一样需要，甚至因为协程更加容易滥用

@lmshl
这个倒是说得太早，尤其是 Java 世界，要原生支持协程且有一段时间。
即便支持协程，对于协程数量的控制还是要需要的，比如有时候消费延后的 kafka ，积累了几十万数据，任何语言启动几十万协程，都不是一个小代价，会系统抖动，影响其他逻辑。

只是技术上我一直倾向一个观点，不要依赖人，依赖算法，而这个 lib 只是提供了一个依赖人去修改的功能，就很鸡肋。

你这个需求，是为了动态修改线程池状态，但是这个反而不是我们更需要的，
我做了类似的一个线程池框架，最终实现是：

---------------------------------------------------

# Executor 基于命名空间的公用线程池

## 背景

- 合理使用 Java 线程池并没有想象那么容易，容易滥用
- 能否合理做到 try{}catch{}，log ，reject(CallerRunsPolicy/AbortPolicy/DiscardPolicy)
- 在尽量使用资源和防止滥用取得一个平衡

## 设计

- 全局共用线程池，便于管理全部线程，唯一是要注意资源隔离
- 提供梯度降级线程池处理，最大并发控制
- wait group （ fork -> join 模型）
- 监控上报（以 namespace 作为划分）
- 优先级
- 保持和 java.util.concurrent.Executor 一致接口

## 使用场景

### 1. 需要限制最大并发线程数量

比如：kafka 消费，要防止积累的数据瞬间占用大量线程，必要时异步转同步，阻塞消费（典型场景：***）

```
executor.execute("process***", () -> {
handle***(xxx);
}, Opt.withMaxConcurrent(100));
```

### 2. 定义并发上限之后不同表现

```
executor.execute("lowPriority", new Runnable(){...}, Opt.withRejectPolicy());
// CallerRunsPolicy 转变成为当前线程执行
// AbortPolicy 打印异常并且放弃
// DiscardPolicy 默默丢弃
```

### 3. 低优先级

比如： 可以丢失的异步任务，达到最大线程数之后，将放在低优先级 pool （ 64 线程） 执行，相互竞争

```
executor.execute("lowPriority", new Runnable(){...}, Opt.withLowPriority());
```

### 4. fork -> join 模型

比如： 发出多个异步任务，等待集体完成

```
executor.execute("job1", new Runnable(){...}, Opt.withConcurrentGroup("thread-group"));
executor.execute("job2", new Runnable(){...}, Opt.withConcurrentGroup("thread-group"));
executor.execute("job3", new Runnable(){...}, Opt.withConcurrentGroup("thread-group"));
executor.wait("thread-group")
// job 1-3 done
```

### 5. log / monitor

对于开启的任务，都进行 log 和耗时监控，同时上报 monitor

---------------------------------------------------

搞一个全局线程池（最大可能是 2048/4096 ，...），通过同步原语控制并发数（ or 百分比，10%）
来让资源最大化使用，但是同时不至于滥用资源，至于这个控制算法，需要仔细斟酌，这才是核心需要

至于那些资源动态改来改去，最多算是一个 1.0 版本，我们需要的是，让机器帮我们选择，作出决定。

作为程序员，精准量化有必要：
1. 加班频率到底如何，是否影响生活了，还是你意气用事
2. 她对孩子怎么样，付出如何

---
以女方角度，没准是，费心费力代娃，努力工作，加班还被老公吼

这个问题在于一门新的语言，算不算基础学科的一部分

比如数学，大部分人的数学，在初中阶段就够用了；普通程序员，微积分用的都很少，高中水平够了

对于基础学科，就好比有了计算器，我们依然会教小孩数学，并且认为是必须的学科
那这个问题，我依然会教育小孩英语，一门最广泛，各种领域获取资源最便利的一门学科，同时也是文化的一部分

如果你考虑利息这个角度，那么永远都不需要买房，除非像日本那样低利率时代。
核心问题还是：是否需要一个房子，带给你幸福感如何

地方水质不同，饮水机是我对所有人推荐的，不用都不知道水能那么脏

最贵的 RO 反渗透，不过根据我的实测，换了后水质好很多

车贬值和维护成本极高，如果一定要 530 ，可以考虑成色好点的二手车
我第一辆车，15w 落地，五年之后二手 4.5w ，算下来一年 2w 折旧+几 k 维护

阳台柜用铝的比较好，但是卧室用铝柜会不会感觉没那么好的质感

这里有性别差异的：
对于女性来说，颜值影响较大，从各个方面
男性相对没有那么大

并且你这个色弱感觉比我还严重，第一张图 ES 非常明显，第二图我看不出来

说个有趣的事情：
我玩和平精英雨林地图的时候，就是绿油油画面，队友很容易找到人，我都是要到跟前才能看到人
就这地图，对色弱人群都是不友好的，哈哈哈

@changnet 其实你不大愿意承认自己色弱，哈哈

说实话，是不是色弱，很明显的，很简单，你看不出来就是色弱，不管你说的能区分颜色还是看很久看出来
尤其和正常人对比，他们分分钟看出来

像我从小就知道自己色弱，内心毫无波澜

@deorth 是的，有些验证码，我是真看不出来阿

色弱并不影响领取驾照，除非色盲，大部分情况能给你通过，不通过说明真的严重