ASP.NET页面同时多个请求，出现阻塞假死情况

小渣渣

最近做项目，一些页面需要加载大量的数据，有时候，我点击该页面，不等该页面加载完成，然后重新点击别的页面的时候

会出现很慢，网页加载中假死的状态，所以，今天就仔细研究下吧。

一开始，我以为是许多网站都会出现这种情况或者我电脑网速的问题，但是，我发现本站，并没有出现过这种情况，有时候，我发帖的时候会卡住，但是，我在选项卡点击其他的页面可以很快的加载出来。

今天仔细研究下吧！！！先上测试的代码：

首页view代码：

登录可见。

控制器代码：

登录可见。

测试代码分析，我们控制器有3个方法，一个是首页，其他两个是测试方法

Test1请求会阻塞5秒，然后返回数据给用户

Test2请求不会阻塞，会直接返回数据给用户

我们首页是用Ajax请求的两个接口，Ajax是异步请求，所以，并不存在阻塞这个问题，

我们会发现，Test1方法输出完内容，Test2才输出内容（正常来讲，页面会直接输出Test2返回的内容，然后等待5秒输出Test1返回的内容，因为js是不阻塞的）



然后，我们直接访问Test1和Test2接口，我们先访问Test1，然后立马访问Test2，发现Test2必须等到Test1返回完成才会返回，如下图：



如果页面请求设置一个读取器锁定，同一会话中同时处理的其他请求将无法更新会话状态，但是至少可以进行读取。如果页面请求为会话状态设置一个写入锁，那么所有其他页面都被阻止，无论他们是否要读取或写入内容。例如，如果同时有两段程序视图在同一个Session中写入内容，一段程序必须等到另一段程序完成后才能写入。在AJAX程序设计中，必须注意这种情况的发生。

特别说明：只有写Session时，Asp.net才会阻塞请求，但是只要你访问过写Session的页面，比如是用Session登录的系统之后的操作(直到Session失效都一直锁定，当然只是SessionID相同的情况)。都会存在这个问题。

网友资料

只要网站使用了session,那么每次请求就会在整个生命周期中，锁住session,这样同一sessionid的请求就必须等待解锁

这就表示，如果网站有个超时的页面，那就什么事也干不了了，必须等这个超时的页面加载完成。

你同样干不了，同一页面多个ajax并发请求，干不了，消息轮询请求。

总结吧：如果，你带session去请求会出现这种情况，如果，你不带session去请求，不会出现上面情况

解决办法：

控制器 controller 增加 [SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)] 特性

注意：

Required means you are requesting a exclusive lock on Session (i.e. no parallel processing of requests for the same sessionID)
ReadOnly means you are requesting a non-exclusive lock on Session (i.e. your request still has to wait for requests with an exclusive lock to finish, but you can process requests with non-exclusive locks in parallel. However it is up to you to ensure that your code doesn't write to Session. It's not necessarily enforced by the framework)

Required意味着你请求的会话互斥锁（即没有并行处理为相同的SessionID的要求）

ReadOnly意味着你请求的会话非独占锁（即你的要求仍然要等待完成，独占锁的请求但你可以处理与并行非独占锁的请求。但是你要确保你的代码不写会话。它不一定是由框架的执行）

admin

对于WebForm来说是在aspx顶部的Page后面加上(仅仅加载那个阻塞页面)：

EnableSessionState="ReadOnly"

小渣渣

在多数web开发中会使用session来保存会话状态，但是在asp.net的应用中使用session，有可能会对web应用的性能产生不小的影响。为什么会有影响以及会影响什么，下文分析

MSDN对并发请求和会话状态的解释：

并发请求和会话状态
对 ASP.NET 会话状态的访问专属于每个会话，这意味着如果两个不同的用户同时发送请求，则会同时授予对每个单独会话的访问。但是，如果这两个并发请求是针对同一会话的（通过使用相同的 SessionID 值），则第一个请求将获得对会话信息的独占访问权。第二个请求将只在第一个请求完成之后执行。（如果由于第一个请求超过了锁定超时时间而导致对会话信息的独占锁定被释放，则第二个会话也可获得访问权。）如果将 @ Page 指令中的 EnableSessionState 值设置为 ReadOnly，则对只读会话信息的请求不会导致对会话数据的独占锁定。但是，对会话数据的只读请求可能仍需等到解除由会话数据的读写请求设置的锁定。