坦白的说，现在的量没有到非要用高性能异步httpclient的时候，用jdk自身提供的URLConnection足够了，最多为便捷性封装一下。真要考虑性能的话还有其他的解决方案未必一定要选择AsyncHttpClient。它依赖了netty已经不那么轻巧；另外去年我们遇到过tomcat不能正常退出的情况，发现是由这个框架里的某个non-daemon线程引起的，当时在微博上贴过:

ning的AsyncHttpClient 里启动了一个 netty 的 HashedWheelTimer 线程，这个线程挺有意思的，本来父线程已经是 daemon 的了,但使用 jdk 的 DefaultThreadFactory 给显式的 setDaemon(false) 了，致使这个线程一直以 non-daemon 方式运行， tomcat正常的stop没法结束这个 non-daemon 线程，要kill才行

"Hashed wheel timer #3" #44 prio=5 os_prio=0 tid=0x000000000a3a5000 nid=0x1ac5 waiting on condition [0x0000000043c70000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at org.jboss.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:445)
    at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:364)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at java.lang.Thread.run(Thread.java:745)

估计作者并未考虑在servlet容器里使用的情况，当时没有找到有效的方法解决，也没时间去深入了解，直接切换到JDK的URLConnection。

当然我是针对我们的场景，如果你在使用AsyncHttpClient时也遇到non-daemon线程的问题，可以参考一下当时姜宁的回复(可以给AsycnClient提个patch， Netty HashedWheelTimer 的构造支持替换 ThreadFactory)，对创建HashedWheelTimer的线程工厂做一下手脚。