因此，最近几乎所有平台提供商都非常重视提供新的工具/语言结构以实现更好的并发性。这也是为什么函数式编程语言的许多想法被集成到C＃，Java等主流语言中的原因之一。
尽管今天特别是在引入多核CPU的情况下这些很有意义，但我想知道如何在Web应用程序领域中特别使用它们。在Web应用程序中，很多并发性由Web服务器本身管理，我很少看到在Web页面中实现的多线程。 AJAX还启用了像“范例”这样的范例来进一步帮助。
Web应用程序通常包括快速获取结果，直到现在我们已经使用了许多策略，如缓存，冗余等来实现此目标。如果存在计算密集型的东西，则必须离线（并且客户端可以稍后查询结果或者可以实现回调）。
并发类已经在很多库/框架中实现，这些库/框架通常用在像数据库这样的Web应用程序中，在memcached这样的框架中多次获取。
我找不到很多示例场景，其中最近的并发平台和库可以在Web应用程序的上下文中使用。所以我想知道它们在网络领域是否有很多意义。
答案 0 :(得分：6)
由于Web应用程序默认是并发的，因此您不太可能在Web应用程序中使用新的并发机制（例如TPL或PLINQ for .NET）。在高负载的Web服务器上通常不会获得任何结果（通过减慢另一个请求，可以加快一个请求）。但是，如果您的专用Web服务器不能满足大多数CPU周期（同时具有多个内核），那么这些技术可能会很有用。
[更新：] 只需阅读new article上的Parallel Programming with .NET blog即可。这是两个有趣的引用：
在大多数情况下，尤其是 它使用频繁的Web应用程序 可能没有必要介绍 额外的并行性，因为添加更多 工作项只会导致 竞争CPU时间和 最终降低请求吞吐量。
和
需要执行的Web应用程序 昂贵的计算可能仍然存在 从并行性中获益 单个请求的延迟是 比整体要求更重要 吞吐量。
我认为这可以回答你的问题。
答案 1 :(得分：4)
对同步和一致的所有内容的严格看法并不能很好地扩展。然后有一种趋势是拥有更多的东西异步并接受最终的一致性。这也反映了语言和框架的设计方式。
很多灵感来自功能区域，因为它非常适合这种计算模式。函数式编程有助于推理 要执行的内容，而不是 和 时的。
这实际上是补充处理并发的传统机制。
我找不到很多样本 最近的情景 并发平台和库 可以在Web应用程序的上下文中使用。所以 我想知道他们是否做了 在网络领域很有意义。
这取决于你的意思。您不必使用低级构造，例如java.util.concurrent中的构造。但是在框架堆栈中支持更好和更好的异步。例如，Servlet 3.0引入了异步Web请求，以简化 AJAX 应用程序的开发。因此，EJB 3.1具有异步方法调用以与异步Web层集成。在底部，我们有函数（或委托，闭包）的低级抽象，它抽象计算本身，以及计算所需的信息（其上下文）。我想.NET也是如此。
与传统的Web应用程序无关，而是与网络“云”相关，函数式编程有助于跨CPU和节点的分布式计算。一个众所周知的例子是map / reduce等，它们旨在处理大量数据。
所有这些组合在一起，我们看到一个Web应用程序保持响应，而大量数据集是异步处理的。
但不，你不需要为传统的网络应用程序提供所有这些！
答案 2 :(得分：2)
答案 3 :(得分：1)
坚持你的问题......
如果存在计算密集型的东西，则必须离线（并且客户端可以稍后查询结果或回调可以实现）。
这正是有时需要后台并发（在服务器上）的部分，并且优于Ajax生成的Web线程：
答案 4 :(得分：0)
当然，并发平台在Web应用程序中很有意义。举几例来看SO（和多租户框架StackExchange） - 必须有很多情况下同时更新同一个对象（问题，答案等）。这将是我想象的这种软件的一个重要考虑因素。
答案 5 :(得分：0)
关于Web应用程序中的所有并发性都基于多用户体验。通常它只是“每个用户一个进程”，没有共同点，可能只在数据库级别连接，但是像Flockdraw，usteream和其他将多个用户实时组合在一起的应用程序，通过多个线程保持它们互连和同步用户，但实时积极地相互交流。
答案 6 :(得分：0)
据我了解，问题来自于概念并发的两个不同含义的复杂性：网站的并发服务对用户请求（宏级别）与两个并发执行程序/流程/线程（微观层面）。
他们使用相同的单词并发，但前者是同类，如果我们只是假设服务器只提供一个服务，并且之间没有交互/共同提供给不同用户的宏级服务。即使针对不同用户的服务进入数据存储级别并因此争用IO资源，这更多地是微观层面的问题：两个查询/写入针对公共资源相互竞争。作为一种抽象，提供给用户的服务总是同质的，因此平台提供的并发功能/库（您的意思是Java，.Net等等）与Web应用程序无关，但只有微操作远远低于它们。