我理解使用blocking通知线程池您传递给它的代码块包含长时间运行或阻塞操作。允许池暂时产生新工人，以确保永远不会发生饥饿。我在某些地方使用blocking块，但现在认为继续使用带有默认执行上下文的blocking块可能并不理想，因为在创建临时工作者然后销毁它们等时必须有相关的成本。相反，我可以创建单独的执行上下文以运行阻塞调用，以避免创建/销毁工作线程的成本，但在专用执行上下文中具有足够的池大小。或者可以使用ONE executioncontext并继续使用blocking块？
基本上所有的db调用都是阻塞的，它们将被包装在async{blocking{}}中（如果继续使用一个ExecutionContext）。可能有一百个或更多DAO阻止API。可能有数千名用户访问该系统。