好的，非常感谢Joel Muller的贡献。我的最终解决方案是使用自定义SessionStateModule在这篇MSDN文章的最后详细说明:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

这是:

非常快地实现(实际上似乎比走提供者路线更容易) 使用了很多标准的ASP。开箱即用的网络会话处理(通过SessionStateUtility类)

This has made a HUGE difference to the feeling of "snapiness" to our application. I still can't believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu...

对于ASPNET MVC，我们做了以下工作:

缺省情况下，设置SessionStateBehavior。通过重写DefaultControllerFactory对所有控制器的动作进行只读 在需要写入会话状态的控制器动作上，用属性标记将其设置为SessionStateBehavior。要求

创建自定义ControllerFactory并覆盖GetControllerSessionBehavior。

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

AcquireSessionLockAttribute

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

在global.asax.cs中连接创建的控制器工厂

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

现在，我们可以在一个Controller中同时拥有只读和读写会话状态。

public class TestController : Controller 
{
    [AcquireSessionLock]
    public ActionResult WriteSession()
    {
        var timeNow = DateTimeOffset.UtcNow.ToString();
        Session["key"] = timeNow;
        return Json(timeNow, JsonRequestBehavior.AllowGet);
    }

    public ActionResult ReadSession()
    {
        var timeNow = Session["key"];
        return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
    }
}

注意:ASPNET会话状态即使在只读状态下仍然可以被写入 模式，不会抛出任何形式的异常(它只是不锁定 保证一致性)，所以我们必须小心地在控制器需要写入会话状态的动作中标记AcquireSessionLock。

我开始使用angieslist。redis。RedisSessionStateModule，除了使用(非常快)Redis服务器存储(我使用windows端口-尽管也有一个mopentech端口)，它绝对没有锁定会话。

在我看来，如果你的应用程序结构合理，这不是问题。如果您确实需要将锁定的、一致的数据作为会话的一部分，那么您应该自己专门实现锁/并发性检查。

微软决定每一个ASP。在我看来，为了处理糟糕的应用程序设计而默认锁定NET会话是一个糟糕的决定。特别是因为大多数开发人员似乎没有/甚至没有意识到会话被锁定，更不用说应用程序显然需要结构化，以便您可以尽可能地实现只读会话状态(在可能的情况下选择退出)。

对于遇到这个问题并且发现没有任何解决方案有用的Mono用户，您没有做错任何事情。 Mono (Issue #19618)中有一个bug，使得SessionStateModule上的SessionStateBehavior无用，所以在Web上设置SessionStateBehavior并不重要。config/pages, Application_BeginRequest，或者在控制器或动作上设置一个属性。什么都不行。我试过了。

然而，防止锁定的逻辑(在SessionStateModule上调用GetItem而不是GetItemExclusive)有一个限制:HttpHandler必须实现标记接口IReadOnlySessionState。

因此，我没有实现我自己的SessionStateModule，而是采用了一种不同的(有点笨拙的)方法。

供贵方考虑:

// Custom handler that derives from MvcHandler which implements IReadOnlySessionState
public class MvcReadOnlyHandler : MvcHandler, IReadOnlySessionState
{
    public MvcReadOnlyHandler(RequestContext requestContext) : base(requestContext)
    {
    }
}

// Custom RouteHandler that derives from `MvcRouteHandler` which
// returns our very own `MvcReadOnlyHandler`
public class MvcConcurrentRouteHandler : MvcRouteHandler
{
    protected override IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return new MvcReadOnlyHandler(requestContext);
    }
}

// On Global.asax.cs Application_Start, after all the Routes and Areas are registered
// change only the route handler to the new concurrent route handler
foreach (var routeBase in RouteTable.Routes)
{
    // Check if the route handler is of type MvcRouteHandler
    if (routeBase is Route { RouteHandler: MvcRouteHandler _ } route)
    {
         // Replace the route handler
         route.RouteHandler = new MvcConcurrentRouteHandler();
    }
}

因为现在路由器实现了ireadonlyessionstate，所以没有锁定会话id

希望当这个bug被修复时，我的解决方案将是多余的，但在那之前，我希望它能帮助到别人。

Important note: This solution basically makes storing items on the Session unsafe, I don't use this feature so for me it works. You can still add items since ReadOnly does not prevent writing, it is just not locking. If you want to guarantee safe writing, you can add another extension method MapRoute to RouteCollection to use the new router, in order to register routes that doesnt lock. Like that you can register your routes to new MvcConcurrentRouteHandler router or to the existing one for writing.

好的，非常感谢Joel Muller的贡献。我的最终解决方案是使用自定义SessionStateModule在这篇MSDN文章的最后详细说明:

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

这是:

非常快地实现(实际上似乎比走提供者路线更容易) 使用了很多标准的ASP。开箱即用的网络会话处理(通过SessionStateUtility类)

This has made a HUGE difference to the feeling of "snapiness" to our application. I still can't believe the custom implementation of ASP.Net Session locks the session for the whole request. This adds such a huge amount of sluggishness to websites. Judging from the amount of online research I had to do (and conversations with several really experienced ASP.Net developers), a lot of people have experienced this issue, but very few people have ever got to the bottom of the cause. Maybe I will write a letter to Scott Gu...

只是为了帮助解决这个问题(当从同一个会话执行另一个请求时锁定请求)…

今天我开始解决这个问题，经过几个小时的研究，我通过从全局中删除Session_Start方法(即使为空)解决了这个问题。asax文件。

这在我测试过的所有项目中都有效。