2018/07/02 08:55

发表了资讯评论：

多谢支持😄

Play Mongo 0.2.0 发布，新增 implicit macro 方法

2018/05/04 19:21

发表了博客评论：

scala macro 一直在易用性和灵活性之间做权衡，似乎 Scala 3 也没有找到完美的平衡点：https://www.scala-lang.org/blog/2018/04/30/in-a-nutshell.html

Scala Macro 现状介绍

2018/04/28 21:35

发表了博客评论：

sbt是支持增量编译的，升级到最新的sbt版本试试呢？如果项目太大，也可以考虑拆分子项目。

【长期更新】Play-Java开发技巧问答

2017/11/15 09:30

发表了资讯评论：

竟然没提Scala？#PlayScala#

微软首席研究员：函数式编程语言时代已经来临

2017/10/28 13:48

发表了博客评论：

Scala 2.12 提供了更好的解决方法：Future.flatten

PlayScala实战 - 如何优雅地取出多层Future中的结果？

2017/10/24 13:57

发表了博客评论：

Servlet规范可以为商业或开源的Servlet容器实现提供参考，好处是我们可以有很多的Servlet容器可以选择，坏处是限制了Java Web开发的想象力。其实我们真的需要那么多的Servlet容器吗？我想这也是Play Framework不支持Servlet规范的原因之一。脱离了Servlet，异步其实很简单，这是Play中的异步Action代码：
def index = Action.async {
// 执行业务操作(可以选择在业务线程池上执行)
val asyncTask = Future { do heavy work... }
// 将执行结果转换成Http Result写回给客户端
asyncTask.map{ result => Ok("Result is" + result) }
}

servlet3异步原理与实践

2017/05/18 10:41

发表了博客评论：

抱歉，内容太多，超出了回复长度限制，所以分成两个回复。另外代码的缩进在提交时竟然被去掉了！😓

Play Scala 2.5.x - Play with MongoDB 开发指南

2017/05/18 10:37

发表了博客评论：

执行一次之后输出结果如下：
f1 runs on thread 11
f3 runs on thread 13
f2 runs on thread 12
f1's callback runs on thread 13
f2's callback runs on thread 14
f3's callback runs on thread 13
f's callback runs on thread 13
从上面的结果可以看出，Future的回调会在随机的线程上执行，当有大量这种回调时，会出现频繁的线程切换。如果是同步调用方式，所有操作只在一个线程内执行，没有线程切换开销。

Play Scala 2.5.x - Play with MongoDB 开发指南

2017/05/18 10:31

发表了博客评论：

业务逻辑层的线程切换是指Future的回调函数会在随机的线程上执行，大量的这种回调会导致线程池中的线程频繁切换上下文，例如：
val f1 = Future{
println("f1 runs on thread " + Thread.currentThread().getId)
"f1"
}
val f2 = Future{
println("f2 runs on thread " + Thread.currentThread().getId)
"f2"
}
val f3 = Future{
println("f3 runs on thread " + Thread.currentThread().getId)
"f3"
}
通常我们利用for语句取出结果：
for{
r1 <- f1
r2 <- f2
r3 <- f3
} yield s"${r1}-${r2}-${r3}"
但在编译时会被转换成如下形式，所以我们采用下面这种形式进行测试：
val f: Future[String] =
f1.flatMap{ r1 =>
println("f1's callback runs on thread " + Thread.currentThread().getId)
f2.flatMap{ r2 =>
println("f2's callback runs on thread " + Thread.currentThread().getId)
f3.map{ r3 =>
println("f3's callback runs on thread " + Thread.currentThread().getId)
s"${r1}-${r2}-${r3}"
}
}
}

f.map{ f =>
println("f's callback runs on thread " + Thread.currentThread().getId)
s"${f1}-${f2}-${f3}"
}

Play Scala 2.5.x - Play with MongoDB 开发指南

2017/05/16 19:05

发表了博客评论：

和您聊天获益良多，非常感谢！
目前看来MongoDB在性能上确实没有优势，我们选择它的原因是因为符合我们的业务场景，而不是为了提升系统性能。希望MongoDB能够发展的更好，兑现它宣传的性能。
关于异步我觉得要分两层进行讨论，第一层是底层的异步IO实现，就像您上面说把异步理解为“由事件驱动的一个状态机”，这一点我赞同您的观点，可以用一个EventLoop线程高效地处理底层IO，并且没有线程切换开销；第二层是上层的异步业务逻辑实现，即已经获取到数据开始进行后续的业务处理任务。假设我们目前有10个同步阻塞的业务方法，需要把这10个方法重构成异步代码，平均每个方法内部将产生10个异步调用，原本这10个业务方法串起来执行时无需线程切换，但是重构成异步之后却需要100次线程上下文切换。

Play Scala 2.5.x - Play with MongoDB 开发指南

2017/05/15 11:11

发表了博客评论：

首先恭喜大牛的ActFramework在TechEmpower测试中战绩喜人，是国人的骄傲！另外我想对您提到的两点(MongoDB性能问题和异步驱动)发表一些拙见，如有错误还望指正。
MySQL和MongoDB分别是为不同场景设计的产品，所以放在一起比较不太合适。就并发粒度而言，MySQL是事务级，而MongoDB是线程级，所以理论上MongoDB的性能会高出很多，在TechEmpower的测试中MongoDB的读场景优势还是很明显的，但是在Update测试中却落后了一大截，我觉得主要原因可能是因为MongoDB太年轻，毕竟还不到10岁，而MySQL已然20多岁了，在技术积累上不在一个量级；另外，Update测试也不符合真实的业务场景，即一些复杂的事务在高并发时会出现交叉，从而导致MySQL性能急剧下降。
关于异步驱动问题，不可否认的是同步驱动的rps和平均响应时间一定高于异步，因为异步增加了很多线程切换开销，但是同步的局限在于并发数受限于CPU线程数，而异步即使很少线程也能实现高并发，另外同步的风险在于，如果系统存在高延时的阻塞代码，则会迅速耗尽所有的CPU线程，导致系统无法正常服务，出现大量请求超时。

Play Scala 2.5.x - Play with MongoDB 开发指南

2016/12/14 09:27

发表了博客评论：

竟然遗漏了MongoDB！

2017 年你应该学习的编程语言、框架和工具

2016/12/02 09:16

发表了博客评论：

Play👍

你应该知道的9款流行 Web 框架及其优缺点

2016/07/26 09:01

发表了博客评论：

非常好，赞一下！