高并发访问下VB.NET网页功能异常原因咨询（负载均衡环境）

一、大量用户访问是否会引发此类问题？ #

高并发访问本身不会直接触发这类前端交互异常，但会通过影响后端资源分配、状态同步等环节间接引发问题，具体机制如下：

• 服务器资源耗尽导致响应延迟：当服务器CPU、内存或IIS连接数达到瓶颈时，后端生成页面片段、处理请求的速度会大幅下降。如果清除按钮的逻辑依赖后端返回的状态同步，延迟可能导致前端接收的状态不完整，进而出现复选框未全清的情况。
• 线程池耗尽引发请求排队：.NET 1.1默认线程池工作线程数仅为25，高并发下线程池会快速耗尽，后续请求进入排队状态。如果清除操作的请求被长时间排队，前端可能重复触发请求，导致状态混乱，最终表现为复选框未全部清空。

二、其他核心潜在原因（结合负载均衡环境） #

1. 会话状态跨服务器同步缺失 #

负载均衡环境下，若未配置跨服务器的会话状态存储（仍使用默认的InProc模式），用户请求被切换到其他服务器时，新服务器无法获取原服务器上的会话数据：

• 若复选框的选中状态存储在Session中，清除按钮触发的会话状态修改仅在当前服务器生效，当用户后续请求被路由到未同步的服务器时，页面会加载旧的会话状态，导致部分复选框看起来未被清除。
• .NET 1.1的InProc会话依赖进程内存，高负载下应用池更易因资源耗尽触发回收，直接导致会话丢失，进一步加剧状态不一致问题。

2. IIS缓存策略不一致 #

如果页面或复选框相关的前端脚本被IIS配置了输出缓存，不同服务器的缓存可能因更新时间差、缓存策略差异出现不一致：

• 当清除按钮的逻辑依赖前端脚本处理，而用户请求被路由到缓存了旧版本脚本的服务器时，脚本逻辑可能无法正确遍历或处理所有复选框，导致清除不彻底。
• 高负载下，IIS会优先返回缓存内容以降低资源消耗，进一步放大缓存不一致带来的问题。

3. 前后端状态的竞态条件 #

高并发场景下，同一用户的多次请求或多用户的并发操作可能导致前后端状态出现竞态：

• 比如用户快速点击清除按钮多次，前一个请求还未完成状态更新，后一个请求已经发送，导致后端状态被多次修改，最终返回给前端的状态混乱，表现为部分复选框未被清除。
• .NET 1.1的单线程请求处理模型，在高并发下请求上下文切换频繁，可能导致状态变量的读写出现异常，加剧竞态条件的影响。

4. 应用池回收导致的内存状态丢失 #

Windows 2008R2的IIS 7.5默认会根据内存占用、请求数等条件自动回收应用池，高负载下应用池回收频率会显著提高：

• 若复选框的状态依赖应用池内的内存对象（比如静态变量、进程内缓存），应用池回收后这些对象会被销毁，新请求会初始化新的对象，导致状态不一致，清除操作无法覆盖所有复选框。

内容的提问来源于stack exchange，提问作者Sai Teja