play framework 中使用线程及锁的问题

最新推荐文章于 2020-04-23 15:47:45 发布

孙大大

最新推荐文章于 2020-04-23 15:47:45 发布

阅读量4.2k

点赞数

CC 4.0 BY-SA版权

分类专栏： play framework

本文链接：https://blog.csdn.net/suncaishen/article/details/42490291

play framework 专栏收录该内容

42 篇文章

订阅专栏

本文探讨了在Play框架中为何不应在控制器的Action中使用锁和线程，因为这会导致请求处理阻塞。文章介绍了如何利用Promise和await来实现异步操作，以避免阻塞并提高应用性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在controller的action中使用锁和线程要特别小心，最好不要使用。

这是由于play在处理多个请求时实际上是复用的一个线程，而不像struts之类的框架，每个请求一个线程一个对象。

所以如下例子中

public class TestC extends Controller{
      public static void t(){
           synchronized(TestC.class){
               Thread.sleep(10000);
           }
           ok();
      }
  
      public static void t2(){
           ok();
      }
}

你会发现不仅是路由 t 的请求被阻塞，就连t2的请求也被阻塞了，play框架在处理所有请求时只使用了若干个有限的线程进行线程复用，个数一般和CPU核心相等，主要是为了提高性能，比较频繁的创建和销毁线程是比较重的行为。

那要例子中的操作应该怎么办呢？play引入了await方法和Promise对象，Promise继承了java 并发框架中的Future

这样写

Promise<String> delayedResult = veryLongComputation(…);
String result = await(delayedResult);

具体示例就是

await(new Job<Long>(){
	@Override
	public Long doJobWithResult() throws Exception {
			synchronized(TestC.class){
			   Thread.sleep(10000);
		    }
			return null;
	}
}.now())

这样其实就开启了另外一个线程,本次请求被挂起但是线程并未阻塞，其它请求仍然可用

参考：https://www.playframework.com/documentation/1.3.x/asynchronous 的Continuations部分的内容