java 的类库这么多，找一个符合你要求的就可以了。

直接 window 开发，然后部署到 linux 上就可以了。

去哪儿的 app 首页有二十多个接口。

axum+1

@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 测试工具。

1.秒杀直接上 redis ，把课程 Id 和对应的数量放到 redis 里，抢到后往消息队列发消息，然后通过消费者处理后续的流程。
2.redis 满了之后可以设置过期策略。把策略设置一下就好。
3.这是扩展题。发现性能瓶颈，然后通过削峰、限流、扩容、分表等手段让系统平稳的处理流量。

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

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

@Tyrant1984 感谢大佬解惑！

香港的服务业已经是粪坑了，国内哪个 1 、2 线城市的服务业不吊打香港？香港本地人都受不了本地的服务业了，来深圳旅游了。

手机通过 AI 算法进一步积压了相机的生存空间，手机镜头不行，但是算法优化的好啊。

相机以后注定是小众玩家的爱好了，小众玩家的产品价格肯定要涨的。

不好意思把标题读成了:

逆天！干! 3 年的同事用 XXXX

这不是指定了 798 的秦吗。。。

@drymonfidelia 客户端从上面的报错信息看线程池还有很大空闲

你的报错信息展示的都是.net 的线程池信息，并没有 redis 服务端的监控信息。