为什么.net支持不了高并发？
.NET不支持高并发？这个你得问问StackOverflow同意不同意，毕竟它最有发言权；在全球，它在编程和软件开发方面排名于17位。
就算StackOverflow同意，我司还不同意。我司并发上亿级的并发核心服务是用.NET Core开发，升级到.NET Core 8之后，性能提升了好几倍。比如，将其中一个较老的超高并发服务由同步改写为异步，吞吐性能瞬间提高了4倍多。
在比如，半导体行业中使用的FDC系统、Bing浏览器、腾讯支付、5173、51job、MS/AAD账户网关、国外的很多金融大型项目等，都用.NET开发，一样能够实现高并发。
.NET能不能做到高并发，完全取决于了架构师和程序员的能力，毕竟大部分的业务系统并发瓶颈主要受限于数据库的I/O，这才有了后来的异步削峰缓存、读写分离集群等，都是为了解决数据库的I/O瓶颈，和编程语言本身没有太大的关系。
如果你的服务器资源有限，开发水平够高，这种情况下.NET能够做得更好，因为.NET对底层调优方便、性能也很好。
使用.NET自带的Task、Socket、Parallel等实现高并发，1万个TCP连接还是可以正常收发，到10万个左右时就会崩溃了。
这时候你可以借助使用第三方库，如Netty for .NET，单机达到百万个连接是完全没有压力。
甚至可以很明确的告诉你，在流量环境一样时，.NET实现的高并发不需要任何优化，RPS过万完全没问题，能够承受的吞吐量是JDK21开虚拟线程的三倍左右，也比WebFlux和Vert.x高。
而采用Java开发时，不仅差距会很大，你还会碰到一个又一个的坑，比如内存、线程、各种容器等问题，让你苦不堪言。
所以，不要随便把CLR平台和JVM平台进行对比，这两者完全没有对比性。
在过去的2024年，.NET的性能已经开始比肩C/C++了，微软招了大量的Rust程序员用于改进.NET。
再加上To C业务几乎已经被大厂垄断，解决高并发问题已经不是什么难事，难点在与如何解决服务器的成本问题。
