这篇文章中貌似还说，其实所有类似的（例如线程池，选择最佳的线程池大小），也基本适用于这个公式。
也就是说，线程池的大小有一个最优的大小。在这个最优的大小下，你的吞吐量、响应时间最优。

这个最优的大小由 C#管理，程序员不用操心。

而 C#的 Task 是什么？ Task 可以简单的理解为“任务”。你不用关心这些“任务”是如何完成的，你只需要知道：可以用 DoSomethingAsync()来开启一个 Task （并获得该 Task 实例）、可以用 await SomeTask 来等待 Task 结束。至于如何完成 Task 的任务，则是 c#的事情——c#会高效利用线程池里的资源，来完成“任务”：在 await 一个阻塞性的 task 时，没有线程会被拿来等待（这也是传统多线程方式无法企及的）。一个 Task 可能会先后被 1 个、2 个、5 个或者多个 worker thread 接手，但这些东西开发者都不需要关心。又由于线程池里 worker thread 的数量设计很合理，所以这种方法能达到最优的表现。

唯一的缺点就是，要严格控制代码（或许 VS 的各种 analyzer 包能容易的做到这一点），不能出现传统的同步阻塞式方法 例如 File.Read()；而是要将它们全都换成 await File.ReadAsync()这种。因为线程池的 worker thread 资源是很宝贵的：核心*2+硬盘数，在 4 核 cpu 下，这个值仅仅为 9。c#可能有一套更优的公式，但也离这个值不远。一旦 worker thread 中运行了同步阻塞式代码，宝贵的线程池资源会被浪费。可能造成 threadpool exhaustion 等问题（这个我不是很懂）,但至少会让吞吐量下降到 线程池大小 /响应时间。

相比来说，感觉 go 的并发代码编写方式、内部实现都很可以。希望 .Net Core 早日达到 go 的性能。

@xingheng 同步方法可以直接执行 DoSomethingAsync()，不用 await。所以就只会存在一个线程（或者几个）不断地接受请求、将请求传至 pipeline，经过各种中间件。从第一个中间件开始，就已经是 async 方法。另外我推测应该是直接调用的 DoSomethingAsync()，不加 await。我再在下文说一下何为“高效管理”。

@xuanbg 并发量和 cpu 核心数的关系粗略的来说是呈线性关系，但具体的下文讲。

先从数据库连接池的最佳大小说起。
连接池的最佳大小：connections = (core_count * 2) + effective_spindle_count。core_count：核心数； effective_spindle_count=貌似是有效磁盘数量。很久以前读的文章，记不太清。
https🐎github.com🐎brettwooldridge/HikariCP/wiki/About-Pool-Sizing

回复测试

@xingheng 这个 working thread 不能说时一直存在的。
假如我调用 await GetDishAsync()，那么 GetDishAsync 任务所用到的线程会被高效管理。
好了，现在问题就来了：GetDishAsync 的 caller 所在的线程（你提到的 working thread ）是否会一直存在？
不是的。因为 await GetDishAsync()的 caller 一定是一个 async 方法，它的线程资源一样会被高效管理。

先学 MDN （ Mozilla Developer Network ），框架的话看官方文档。

哗众取宠

建议使用 edge dev。和 chrome 用起来无区别（透明的）

@MRYuYan 学生党深有体会。我 99%的工作都是在图书馆完成的。

用树来理解。
打印 xx 排列本质上是对树的 dfs、bfs。用理解 dfs、bfs 的思路来理解排列，会很容易。假如不知道，请务必先学习 dfs、bfs。

假设第一步选定的是字母 a，那么接下来就是一个 dfs 过程：
这一层的 a 节点到树的下一层的节点，就只剩下去往 b c d e f...的边了。通往下一层的 a 的边已经不可用。
总结起来，下一层能选择的字母就是：之前未选择过的字母，也就是没出现在路径上的字母。
如果所有字母都用完了，那么意味着生成了一个排列。输出这个排列就是输出 dfs 的路径。

@akakidz
@wangkun025
这只不过是因为人的适应性比较强吧。这种适应性是中性的（时好，有时不好）。
举个例子，玩 csgo 的有人用 144hz 屏幕，他们经常问我：60hz 能看啊？
玩久了 144hz 再去玩 60hz 就觉得 60hz 是一坨屎，但是习惯于玩 60hz 的就觉得 60hz 还好，觉得 144 是流畅了很多但是 60hz 也能接受。

@richzhu
我爸（程序员）前两年强烈要让我妈换 iPhone，就是因为 iPhone 不会中病毒，随便点击都不会出事。

很流畅（ Fluent ）

看看平均情况下，符合 timestamp 筛选条件的行多，还是符合纯 userid 筛选条件的行多。
假如符合 userid 筛选条件的范围的行少，那么就在 userid 加聚簇索引。不敢保证是最优的。
然后和 index(userid,timestamp)还有 index(timestamp, userid)比一比。
最后记得延迟关联。

这个做法问题不大。cookie 中放<token>和放<明文密码>，大多数时候唯一的区别就是取消一个设备对账号的访问权必须修改密码，而采用 access-token 就只用废除 token 即可。其他的关于加密、窃取方面的行为都是没区别的。

即使要甩锅，也是后端的锅：不应该提供 cookie 中明文密码认证的途径。管前端吊事。

微软 asp .net core web 框架的做法是：cookie 附带一个 claim 和 security-token。claim 就是服务器签发的用户名的证明，好像是带签名（ username+signature ）的，密钥存在哪里我没有深究。security-token 每改一次密码或者重新绑定一次电话号码等都会变一下，这样就可以实现账号安全信息变更时自动废除之前的访问权，并且不用向用户呈现“token”或者设备的概念，只需修改密码或者电话号码就一切安全，比较符合自然的逻辑。

@ungrown 好理解

这跟幂等没啥关系。
加应用锁（有业务意义的锁），具体实现可以是分布式锁，用来锁住某个人的某个业务。例如 key="user:66 category=transfer-money"。也可以是对关系型数据库里面的某条记录加 X 锁（独占锁），例如新建一个专门加锁的表。

如果这个转账是多阶段的、多个事务的，那么就应该将数据库里面某个字段作为标志位，在第一个事务里面将标志位设为 1，在最后一个事务结束后设置为 0。其他笔转账想要开启第一个事务的话，首先检测标志位是否为 0，如果不为 0，则表明有一笔处理中的转账。
加锁效率不低。因为没有锁住热点数据，没有争用。

如果想往架构师方向发展（不做普通码农），应该是什么样的学习路线？我之前大致都了解了前后端的很多技术，但都不精细。我前段时间才发现自己在数据一致性上面忽略了很多东西；前几天才发现有个叫 DDD （领域驱动设计）的东西，学了以下发现以前写的思路很丑陋。所以有什么学习路线？（或者能不能给一些专有名词）