apache+tomcat apache线程占满，单各个服务器cpu利用率均特别低

This attribute is a bit mask. The following bits are allowed:
1: don't recover if Tomcat failed after getting the request
2: don't recover if Tomcat failed after sending the headers to client
4: close the connection to Tomcat, if we detect an error when writing back the answer to the client (browser)
8: always recover requests for HTTP method HEAD (even if Bits 1 or 2 are set)
16: always recover requests for HTTP method GET (even if Bits 1 or 2 are set)

This features has been added in jk 1.2.6. Option 4 has been added in version 1.2.16, options 8 and 16 in version 1.2.24.

也就是说，1.2.24及以后版本，的  recovery_options 参数，支持 1 、2、3、8、16 几个选项

1、2两个选项的大致意思应该是，tomcat相应失败的时候，不要去重新尝试，

8、16应该是在失败的时候，去尝试

4，从上面理解感觉就极端了点，直接断开与tomcat的链接？那后面这个tomcat的服务是不是就中止了？

网上有找到这么一段

http://www.esnsc.com/news460.html

recovery_options属性说明了web server在检测到Tomcat失败后如何进行恢复工作。默认情况下，web server将转发请求给处于负载平衡模式中的另一个Tomcat。属性值为0，说明全部恢复；属性值为1，说明如果在Tomcat接到请求后出现失败状况，则不进行恢复；属性值为2，说明如果在Tomcat发送http头给客户端后出现失败状况，则不进行恢复；属性值为3，说明如果在Tomcat接到请求后出现失败状况或者在Tomcat发送http头给客户端后出现失败状况，则不进行恢复。此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。此属性默认为全部恢复。

因在默认的情况下，JK检测tomcat的工作情况，所以浪费了很多资源，这个资源多到比tomcat正常工作所需的资源的1.6倍还多。如果不检测恢复，则效率高了，处理的请求数可以是原来的2.6倍多，而且tomcat还不死--没响应,反而使出错的数量比检测恢复之后出错的数量还少，性能还加强了，如果原来用这种的集群78台机器，有一阵就挂掉，改成这个配置只要30台机器，一般在同样的时间段内运行无反应或出错的情况比recovery_options使用默认值的少。

这个估计是比较早的mod_jk 的参数配置？

最后我尝试了下，配置成3（这个项官网上貌似没有），试了试，竟然连续几天都不再出现apache进程被占满的情况了

worker.tomcat.recovery_options=3

后续继续观察。但有些疑问，为什么这个recovery_options=3，在官方文档上里没写是什么意思呢？目前也不知道 recovery_options=3 到底现在还是不是网文中说的作用。继续观察下吧