我个人觉得，仅仅是开发后端 API 接口（ CRUD ，调接口，连数据库），大部分语言的性能都是够够的，因为接口耗时都集中在网络和文件 IO 上，语言的性能差异被弱化了，无论是 Java 、Go 、Python 、JavaScript 都能写。

后端接口用写 Python ，最大好处是在图像处理和 AI 领域，如果这些领域的团队主要掌握的是 Python ，那么就不用再招额外的其他语言的后端开发了。

剩下的就是团队对于 Python 后端开发规范的统一，不然的话，代码会变得乱七八糟的（当然其他语言也一样），然后有些由于个人使用存在问题，导致接口变慢的问题，就会甩锅给语言本身。

@yumenlong https://pypi.org/project/concurrent-log-handler/ 这个库对么，我试试

@zhangchunjiiw 你在简书写的这篇博客对我很有帮助，感谢

我自己又重新测试了下，假设 1001 对 app.log 进行轮转：

1. app.log 该名称变成 app.log.bak ，但实际上我发现 app.log.bak 的 inode 值没变

2. 1001 进程创建一个新的文件叫 app.log ，然后自己一个人把日志写入到这个新的文件里（新的 inode 值）

3. 1002 进程和 1003 进程被 1001 骗了，还在往 app.log.bak 写日志

大概，似乎，是这样子。。。

@ala2008 之前碰到了 OOM 的问题：java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached

因为我看程序根本没吃满内存，所以我改了 Xms Xmx Xss ，似乎都没啥用，然后我就在一个虚拟机开了俩实例，nginx 负载均衡，结果就再也没报这个错误了。

非常非常感谢大家的回复，我正在开始了解 Java 21 的虚拟线程，希望能用上

使用 MQ 会不会堆积呢，需求是前端对 /demo 发起请求后，后端逻辑（就是顺序请求外部接口的方法）必须要立即执行，引入中间件会不会增加中间的时延。

@yinmin 厉害，有效果，请问这是为什么呢？

@flmn 好的，谢谢你的建议

@Jim2Chen @slomo SpringBoot 3 对于 JPA 还是 MyBatis 的选型，我感觉区别不大，就看团队对哪个更熟悉了，JPA 的很多特性（不是仅仅是简单的 JpaRepository 的 单表 CRUD ）的学习门槛很高，多表的关联，对数据库的设计也很讲究，后期新人维护成本高，我觉得它就是属于那种不会用的人会吐槽到累的，相比之下，MyBatis 更直观一点，国内培训机构都爱用，新人维护成本低。

@spritecn @flmn @cleanery @newaccount
感谢各位老哥的建议，今天已经用上了 Java 21 + Spring Boot 3.3.4 + Spring Security 6.3.3

登陆注册 jwt 两个钟头就全搞好了，剩下的就是权限划分+业务代码了。

除了语法的些微改变之外，最大的感受就是老项目的那些黄色波浪线全部消失了，因为是独立开发的新项目，终于不用再忍受老项目里，各种手写奇奇怪怪的校验工具类，实现类，加密类了，还有毫无意义的自定义抽象和流程（明明框架全部都有，引用了框架，又不好好使用框架，真是最大的槽点）。

最佳实践 + 整齐划一 + 规范的感觉真好，就像是从瘴气雨林来到了大草原。

我接下来会接着学习 Java 21 的新特性，感谢。

@chuck1in @sagaxu 业余时间我会了解下，之前听说过，感觉蛮高级。

@yty2012g DDL 比较宽松，业务上的问题应该也没有，简单的单体，登陆注册权限（ SpringSecurity ），增删改查（ JPA ），加一些定时任务，还有发发邮件之类的，都是以前 jdk8+springboot2.x 做了无数遍的东西。

”所以想尝试下 Java8 + SpringBoot3.x“ 这句话写错了，不好意思，
@sumarker

@sumarker 兄弟这个我知道，所以省略号是什么意思😂

@Leviathann 我刚想问这个哈哈哈哈，直接上 21 是不是更好，一步到胃，接触新的东西多么，之前学 Java8 ，看了本《 Java 8 in Action 》就差不多熟悉了，8 -> 21 有什么比较友好的资料么

昨天刚看完汤浅政明的《心理游戏》。
当我们有手有脚，倘若还有一丝能选择的机会，就有无限可能，不必和他人比较，把整个世界和人生当成一场属于自己的“游戏”，无论从几岁开始都不晚。

@sir283 作为受雇的工作者而言，现场解决问题的工程经验确实是最重要的，毕竟客户的问题，那就是当下最真实的目的，如果现场还能再外包出去（假设有人能更快更好地解决），我可能都不会选择语言，直接让别人做，然后付钱 hhhhhh 。

@billzhuang 作者把这篇文章发到了论坛平台以及自己的个人博客上

编程大部分情况是为了解决某些具体的问题，问题本身可能是很有意义的。
为了在维护项目这个枯燥的过程中不那么苦闷，不得不开始寻找或者赋予工具（比如编程）意义。