問：爲了可以順序訪問Session的狀態值，Session是否提供了鎖定機制？
答：Session實現了Reader/Writer的鎖機制：
當頁面對Session具有可寫功能（即頁面有<%@Page EnableSessionState="True" %>標記），此時直到請求完成該頁面的Session持有一個寫鎖定。
當頁面對Session具有隻讀功能（即頁面有<%@Page EnableSessionState="ReadOnly" %>標記），此時知道請求完成該頁面的Session持有一個讀鎖定。
讀鎖定將阻塞一個寫鎖定；讀鎖定不會阻塞讀鎖定；寫鎖定將阻塞所有的讀寫鎖定。這就是爲什麼兩個框架中的同一個頁面都去寫同一個Session時，其中一個要等待另一個（稍快的那個）完成後，纔開始寫。
webform：
“寫鎖定將阻塞所有的讀寫鎖定”，也就是說頁面在EnableSessionState="True"的情況下沒返回輸出時，一直持着Session寫操作，其他頁面對Session的讀操作必須等待，而asp.net的aspx頁面默認是EnableSessionState="True"，每個頁面從請求開始至返回一直持着Session寫操作，需驗證頁面必須讀取Session值判斷，這就是爲什麼需驗證的頁面請求被阻塞的原因。只要耗時頁面（A頁面）沒有Session的寫操作，也就不會阻塞其他頁面的請求，於是修改A頁面的EnableSessionState="ReadOnly"，
例如：<%@ Page Language="C#" AutoEventWireup="true"CodeFile="Demo_List.aspx.cs"EnableSessionState="ReadOnly" Inherits="Demo_List" %> ，問題解決。
也就是說，在無需對session進行寫操作的頁面，加上EnableSessionState="ReadOnly"屬性，就不會造成Request阻塞的情況了。
mvc：
爲Controller增加以下特性，但是此Controller都不能修改Session了，只能讀取。
[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]