Douyu 0.6.1发布了,这是一个超乎您想象的Web框架

douyu兼容servlet是非常容易的，douyu的基本设计原则是鼓励开发者面向接口编程，
开发者写程序时只要知道底层框架提供了那些接口，
然后在运行时底层框架会把这些接口的具体实现注进来，
javax.servlet和javax.servlet.http这两个包中基本上都是一些接口，
douyu.mvc也是主要由接口组成。

反观playframework框架，看看它的api文档吧，一大堆的类，非常不直观，
api文档完全没有区分框架用户和框架开发人员，有些api用户根本不需要了解。




这个很容易实现的，在@Controller中加个属性就可以了(比如@Controller(singleton=true)).

其实，完全可以不用任何@Controller这样的注解的，
可以默认建个目录比如controllers，所有在这个目录中的类都默认是Controller，
后来我发现这种方式不灵活，如果你要为某个Controller添加一些额外的功能:
比如Controller只能处理POST请求、比如要进行权限认证、比如有最大线程限制，

这时又不得不搞个配置文件在里面配这些参数，这时又回到了在web.xml中配servlet的方式，
所以用注解是最好的办法，注解就是用来设置参数并调整Controller的行为的，
比如@Controller(httpMethods=HttpMethod.POST)就可以做到让这个Controller的所有Action都只处理POST请求，

再比如@Controller(maxThreads=50)，如果这个Controller的某个Action由于执行了某个操作被堵住了，
这个maxThreads参数就能保护系统资源不会被这个Controller耗尽，最多只允许50个线程在并发执行这个Controller，
甚至可以做到按当前系统的服务质量来动态调整所有Controller的行为。

想问下，这个局部变量的使用范围，会不会和其他的全局变量像冲突，另外是不是会把嵌套方法中的局部变量也当做本地变量来使，如果是这样的话，是否会有命名冲突的问题哦，这个变量值以谁为准啊。

根据变量可见性规则，如果局部变量跟全局变量(比如实例变量)同名时，局部变量是会把实例变量覆盖掉的，
我觉得也是可以在模板中加this前缀来解决这些问题，就如同你在java代码中为了访问实例变量加了this一样，

嵌套方法中的变量不会加进来的，

如果在out方法后新定义了一些局部变量，也不能在out(viewFileName)对应的模板中访问的。


最简单的理解是：
这个功能，你可以想像成把模板文件中的每一行内容都内联到java代码中了，像这样:

out.println("....." + localVarName + "....");
out.println("....." + this.instanceVarName + "....");

哦，再请教两个问题：
1.douyu的控制器是不是只能有一个控制方法，如果允许多个方法的话，那么异步调用为每个方法请求公用一个线程池还是单个线程池。
2.douyu的异步action是每个action分派一个线程池，还是全部采用一个线程池

一个控制器可以有多个action，所有的public方法(排除static方法)都是action，都可以通过"/包名/简单类名.方法名"这样的url访问。

首先要说明一点:

异步action是基于servlet3.0规范中的异步servlet实现的，

出现异步servlet的最根本原因是：

当请求处理逻辑走到业务代码时(通常是从进入javax.servlet.Servlet.service方法开始)，
如果业务代码在执行一个很耗时的计算或者调用的服务很久都没结果导致一直在死等，
那么当前线程(正常来说是容器的内部线程)就不能往下走了，就被卡住了，
另外一个同样的请求进来时，容器又要用另外一个线程执行Servlet.service方法,在执行到这个业务代码时也被卡住了,
从而导致容器内部线程池一下就耗尽了，无法执行其他的Servlet。

异步servlet，就是为了解决这个问题，如果开发人员提前意识到业务代码可能把容器的内部线程卡住，
那么此时他就应该用异步servlet，这样这个Servlet.service方法就有可能在一次请求中被重复执行多次，
相当于容器有一个很大的循环，在不停的执行Servlet.service方法，
直到那个很耗时的计算完成或服务超时就可以结束请求。

所以不管是异步servlet还是异步action，这里说的线程池是容器内部的线程池。

当然，在使用异步servlet时，
一般来说应用开发人员都会为这些耗时的计算或者可能会出现问题的服务建立一个公用的业务线程池，
但是这个业务线程池并不是由容器来管理的，即使这个公用的业务线程池被耗尽了，
容器自己的线程池还是可以处理其他类型的请求。

 

呵呵，解释的非常清楚，赞
不过，异步处理最大的挑战在于资源冲突、死锁以及超时处理等问题，综合考虑起来还是挺复杂的。

呵呵，保留意见，不过还是支持开源洞洞

好,很好,very good

过了2个月了才看到斗鱼有新版本了。。晕
09年作者发布第一个帖子时就关注斗鱼，时隔2年再看这篇，感觉作者从理想上升到现实了，而且从作者的回复可见作者对比09已经风轻云淡，异步action，长连接，很是惊喜，支持作者，做事情最精彩的莫过沿途风景，结果不过是过眼浮云罢了，人还是自私点好，对得起自己就行。

哥们，继续支持你，我09年的时候看到了发布了一个斗鱼，到目前2年看了。继续加油。