lsk569937453

@veapon 有什么就说什么，如果你不懂可以不说。做技术的不要拿反问句回答别人。

@veapon 请问我创建线程的时候获取锁耗时 1ms 。而你往阻塞队列塞任务不需要锁，但你任务入队了又不能执行，所以你讨论耗时有什么用呢。

@orzwalker111 我使用线程池当然是通过并发让任务快速执行。难道除了"让任务快速提交执行"之外还有其他的选项吗？

@codegenerator
```
先创建线程如果线程执行完任务就会空闲，空闲等待一定时间就会销毁
这样会有比较多的线程创建销毁
```
既然你喜欢举例，那我就举一个例子。

我们假设线程池的前 n 个任务非常耗时，一直执行不完
"先判断任务队列是否满再判断是否达到最大线程数":如果任务队列长度是 10w ，那么后续提交的 10w 个任务(执行耗时很短)，在任务对列满之前无法执行，需要一直等待在队列中。

结论:大聪明。你完蛋了，准备提桶跑路吧。

如果我的老大给我提个需求要换个框架重构，我都要自己跑路。你还自己提出来，这就是挖坑给自己跳。我自己碰到现实中不得不重构的原因:
1.新来的领导换技术栈，招自己心腹来，把老员工排挤走。
2.公司合并，老的组离职了，老代码维护不了，线上频繁出问题，需要重构。

说下为啥不推荐超大项目重构的原因：
1.重构期间还接新需求吗，你这 700 个接口大概率半年是搞不完的。这半年期间，你不接新需求了吗？如果一边接新需求一半重构肯定对重构进度/接新需求进度有影响(否则就需要招人来做，你和老板说我自己干不过来，那你提重构搞毛啊)。
2.越大的项目需要的回归测试周期越长，有的代码单元测试都没有，就是黑盒。只要这 700 个接口有一个重要接口重构有问题，你就得负责背锅。
3.腾讯的 QQ 重构的时候都会出问题，你是不是觉得你比腾讯的工程师还 6 。

再说下重构的方案:
1.先把当前受影响的接口重构(你生产环境跑的好好的，没有问题。重构就是自己找罪受)
2.不重构，新需求直接上 springboot 那一套。

https://github.com/lsk569937453/rcache

用 rust 实现的 redis ，用 redis-benchmark 测试，4 核 8G 下，rcache 的 tps 是 redis 的两倍。我这还是简单的直接用全局锁一个 Map ，不知道 garnet 用的什么黑科技。

缺点就是 rcache 多线程下 cpu 几乎能跑满，而 redis 的 cpu 一直稳定在 100%左右(这就是单线程的魅力吗。。。)

@iqoo 就是类似 wrk 和 apache jemeter 的 http 测试工具。

https://github.com/donnemartin/system-design-primer

把系统设计读明白，再问架构设计的问题都不慌了。