在系统容量达到极限之时，如果中间件仍旧持续接受请求，则必然会导致应用的稳定性和性能急转直下。WebLogic Server从9系起引入了过载保护这一特性，致力于避免业务系统在已经达到容量极限的前提下依然接受客户端请求。本文以WebLogic 10g R3为例，对此特性进行讨论。
过载保护的几种实现手段
Ø 配置线程池，限制请求接入
WebLogic Server从9系起，所有的请求-无论是内部管理相关或业务请求处理相关，都交由一个统一的线程池处理。系统管理员可以对该线程池所对应队列的排队上限进行定制，从而实现对线程池接受请求的控制：一旦超出了预配置的值，WebLogic Server将会拒绝管理通道以外的所有请求（如果还需限制管理请求的受理，则还可以对管理通道的MaxConnectedClients属性进行配置，设置其为一个期望的数值，以达到对管理请求受理的控制）。
WebLogic Server在排队请求达到上限后开始拒绝的请求包括：
l Web应用请求
l 有较低公平共享值的非事务 RMI 请求，并且首先会由具有最低公平共享值的请求开始
如果超载情况继续存在，则开始拒绝具有更高优先级的请求（JMS和事务相关请求除外，这些请求的超载管理由 JMS 和事务管理器提供）。
限制线程池排队上限可以通过在管理控制台中设置“Shared Capacity For Work Managers”属性实现，此属性值计数内容包括队列中的请求以及正在被执行的请求。该属性默认值为65536，具体请查看“Environments > Servers > serverName > Configuration > Overload”，如下图：
图表 1 shared capacity for work managers
此外，管理员可以对Work Manager进行配置，细粒度地为具有相似性能、可用性或可靠性要求的请求组规划线程池。比如，Work Manager可以指定某个特定请求类的最大允许排队请求数，而此排队请求数将与全局线程池值协同发挥作用，首先达到的限制将生效。
你亦可以手动限制默认线程池的线程数，方法为在java启动命令行添加以下参数：
l -Dweblogic.threadpool.MinPoolSize（下限）
l -Dweblogic.threadpool.MaxPoolSize（上限）
这样的限制将覆盖线程池的自调整算法，避免动态的线程调整，使得Server的并发处理能力在控制之中。
Ø 限制HTTP会话，控制内存使用
管理员可以通过配置实现对并发活跃HTTP会话数量的控制，这对避免内存不足异常非常有用：达到预配的阈值之后，WebLogic Server将会拒绝需要创建新HTTP会话的请求。如果是在WebLogic Server集群环境之中，代理插件会将被拒绝的请求导向至集群中的另一个受管server。如果是非集群的server实例，则会将请求导向至备选的server实例。
其原理为：当一个属于某集群的server的活跃HTTP会话数达到阈值后，servlet容器将会抛出一个SessionCreationException，而应用代码应当对此runtime异常进行处理，并发送一个503响应，该响应将会被代理或负载均衡器捕获，从而实现failover。
并发HTTP会话数的限制可以在部署描述符中进行配置，以下片段实现了并发会话数为12的限制：
<session-descriptor>
<max-in-memory-sessions>12</max-in-memory-sessions>
</session-descriptor>
Ø WLS进程在出现OutOfMemoryError的时候自动退出
管理员可以对WebLogic Server进行配置，使其在遇到内存不足异常时退出。该特征可以帮助你将内存不足所带来负面影响降至最低：首先，自动关闭可以帮助规避应用的不稳定性，其次，你可以通过配置节点管理器或其它的高可用性（HA）工具来实现WebLogic Server的自动重启，从而达到宕机时间的最小化。
为了实现这样的自动机制，你可以在控制台中对Panic Action进行配置（Panic Action指定了WLS内部遇到类似未处理OOME时的应对措施），通过下拉菜单设置其为Exit the server process：
图表 2 设置Panic Action
或者你也可以对WebLogic Server的核心配置文件config.xml进行编辑，加入以下标签片段：
<overload-protection>
<panic-action>system-exit</panic-action>
</overload-protection>
更多关于过载保护的细节，可以参考OverloadProtectionMBean，其所包含的关键私有属性包括：
CachingDisabled
FailureAction
FreeMemoryPercentHighThreshold
FreeMemoryPercentLowThreshold
PanicAction
SharedCapacityForWorkManagers
Ø 对僵死线程进行处理
WebLogic Server会周期性的对僵死线程进行检测。如果所有的应用线程都变为僵死态，server实例便会将自己标识为failed状态，在这样的前提下，一旦存在相应的配置（如对failed状态的响应），server便会自动退出。而一旦server退出，进程停止运行，WLS的自动失败恢复就显得尤为重要：你可以配置节点管理器或第三方高可用性方案以对server实例实施自动重启，从而达到自动失败恢复的目的（笔者将在稍后的文章中对节点管理器配置进行讨论）。
通过配置，你可以确保在僵死线程数量超过阈值，但仍存有部分非僵死线程之时，以下应对措施能够发生：
- 如果存在僵死线程，则关闭相应的Work Manager。被关闭的Work Manager将会拒绝新的工作任务，并通过发送拒绝消息来拒绝队列中已有的工作任务。如果是在集群中，则集群客户端将转切至另一个集群成员。
- 如果应用中存在僵死线程，则关闭相应的应用程序。关闭方法为置应用状态为admin模式。与此同时，所有属于该应用的Work Manager均被关闭，其行为方式与前述相同。
-
如果server实例中存在僵死线程，则标记相应的server实例为失败状态，并将其关闭。如果是在集群中，已连接的客户端以及正在尝试连接的客户端将被转切至另一个集群成员。
WebLogic自监控：
WebLogic的自监控特性满足了WLS对过载状况进行自我检测的要求。当内存过低时，WebLogic Server状态会便会被置为超载，而其健康状态也会由“RUNNING”变为 “OVERLOADED”（由ServerRuntimeMBean的getHealthState方法返回）。
一旦进入了OVERLOADED状态，WebLogic Server实例便开始拒绝来自Work Manager队列中的请求（如果已经配置了Work Manager）：如果是HTTP请求，则会收到503 Error，也即服务不可用；如果是RMI请求，则会在集群化的前提下被切换至另一个server；否则，客户端则会收到一个远程异常。
过载状况结束后，server实例的健康状态将会恢复为OK。此外，作为管理员，你也可以选择挂起或关闭状态为“OVERLOADED”的server实例。
WebLogic Server退出代码
WebLogic Server进程在退出时会返回一个退出码。该退出码可以用于shell脚本或HA代理，以帮助其确定是否需要进行WebLogic Server的重启。
