月度归档：2015年09月

Actor里的偏函数与性能

发表于由
4

Evan Chan分享的《Akka in Production: Our Story》是一篇非常务实的工程实践分享，里面有很多可借鉴的点子，其中的一个对消息接受的包装逻辑主要预留了扩展点：

trait ActorStack extends Actor {

    def wrappedReceive: Receive // Receive类型是一个偏函数

    def receive: Receive = {
        case x => if (wrappedReceive.isDefinedAt(x)) wrappedReceive(x) else unhandled(x)
    }
}

大部分人在实现业务逻辑时可能如下

class MyActor extends ActorStack {

    def wrappedReceive: Receive = {
        case Something => balabala
    }
}

这种情况下会有个小小的性能浪费，每次接收消息的时候，至少要创建一次偏函数对象。如果消息又正好在wrappedReceive里定义了的话，创建了2次偏函数对象，因为调用了2次wrappedReceive方法；这个是可以避免的，用一个成员把这个偏函数对象保存起来，避免每次都创建：

trait ActorStack extends Actor {

    def wrappedReceive: Receive

    private val logic = wrappedReceive

    def receive: Receive = {
        case x => if (logic.isDefinedAt(x)) logic(x) else unhandled(x)
    }
}

或许看客们又好奇，那么Akka对receive这个函数返回的偏函数又是怎么处理的？是否也存在每次都生产一下(同样的性能浪费)，还是保存在某个地方？ 没错，它在底层实现里是被放到behaviorStack这个行为栈里的，每次处理逻辑的时候从行为栈里取出这个偏函数进行调用。

Patterns.ask 是使用一个临时创建的actor发消息而非自身

发表于由
3

用ask发消息给另一个actor时，在接收方收到消息时对发送者做了watch，但发现并不是目标actor，而是一个临时的actor: Actor[akka://AkkaActorSystem/temp/$a]

发送者actor里的逻辑：

val f = targetActor ? Register
Await.result(f, timeout.duration)

接收者actor里的逻辑:

case Register => {
  this.observable = sender
  watch(sender)
  become(...)
}

后来发现这个是因为ask模式就这么设计的，它使用一个临时创建的actor来转发消息并等待对方返回。

跟踪到ask方法内部，是创建了一个PromiseActorRef:

val a = new PromiseActorRef(provider, result)产生了一个临时的Actor[akka://AkkaActorSystem/temp/$a] 被用来代替当前actor发送消息给目标，当它接收到目标回应的结果后，会被卸载掉。

shell前边的连字符含义

发表于由
回复

在一个脚本里，要获取其父shell时，使用了下面的方式：

#!/bin/bash 
ps -ocomm= -p $(ps -oppid= $$)

它在某些环境下，父shell会显示为 “/usr/local/bin/zsh” 或者 “bash” ，而某些环境下却会显示为”-bash”或”-zsh”；这个开头多出来的连字符是怎么回事？查了一下，原来是表示的是”login shell”。

linux下可以在”/etc/passwd”里看到用户的login shell，而在mac下要确认当前用户的login shell，要通过下面的命令:

$ dscl . read /users/$USER UserShell
UserShell: /bin/bash

在mac下，当打开终端程序(Terminal.app)时，终端shell是login进程的子进程(不管你配置那种command):

$ pstree
 ...
 |-+= 01272 hongjiang /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
 | \-+= 01275 root login -pf hongjiang
 |   \-+= 01276 hongjiang -bash
 ...

$ ps -ef | grep login
0  1275  1272   0  2:05PM ttys000    0:00.05 login -pf hongjiang 

# 把Terminal的启动命令修改为zsh也一样

 |-+= 01988 hongjiang /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
     | \-+= 01991 root login -pf hongjiang /bin/zsh  |   \-+= 01992 hongjiang -zsh

而在mac的 iTerm.app 下，不管如果你配置的command是”Login shell”还是修改为其他shell，启动后shell没有再挂在login进程下:

$ pstree
 |-+= 00574 hongjiang /Volumes/Data/program/iTerm.app/Contents/MacOS/iTerm
 | \-+= 02177 hongjiang /usr/local/bin/zsh

但在iTerm下如果使用的是“Login shell”显示的名称前边却是有连字符的，而其他shell则没有

$ ps $$
  PID   TT  STAT      TIME COMMAND
 2220 s001  Ss     0:00.01 -/bin/bash

# 修改启动shell为zsh

➜  ps $$
  PID   TT  STAT      TIME COMMAND
 2524 s000  Ss     0:00.16 /usr/local/bin/zsh

要想在iTerm下保持跟Terminal一致也用login来启动，应该在配置里修改启动命令为：

login -pf $username /usr/local/bin/zsh

在linux下，从tty登录shell也是一样由login进程启动的

$ ps -ef | grep bash
 hongjia+  2241   467  0 14:09 tty1     00:00:00 -bash

$ pstree 
systemd─┬─NetworkManager─┬─2*[dhclient]
    │                └─3*[{NetworkManager}]
    ├─...
    ├─login───bash
    ...   

$ ps -ef | grep login
root       467  0.0  0.2  84584  2328 ?        Ss   14:08   0:00 login -- hongjiang

使用su命令切换到一个用户shell下，默认情况这个shell并不是”login shell”不会去执行/etc/profile和home目录下相关配置：

$ sudo su hongjiang

$ ps -ef | grep $$
hongjia+  2796  2795  0 14:57 pts/0    00:00:00 bash

要以”login shell”方式启动，需要对su指定一个参数“-“

$ sudo su - hongjiang

$ ps -ef | grep $$
hongjia+  3188  3187  0 15:35 pts/0    00:00:00 -bash

从bash文档里可以看到，要以”login shell”方式启动一个shell，要么第一个参数给一个特定的连字符“-”，要么显式的对bash设定”–login”参数。

每次输出日志前需要判断日志的级别吗?

发表于由
1

早期使用log4j/common-logging的时候，出于性能的考虑(非该级别，字符串拼接造成的额外开销)，会将判断日志级别作为一种编码规范:

if(logger.isDebugEnabled()){
   logger.debug("debug information: " + xxx);
}

后来slf4j接口里为了避免过早字符串拼接可能引起不必要的开销，将其推迟到了要打印的时候才拼接，可以不必显式的加一次if判断:

logger.debug("my name is {}", name);

但是问题是即使用的是slf4j的api，应用中并不能保证大家都采用format形式的写法，依然很多用加号直接拼接字符串的情况。所以简单的原则是强制所有的日志都必须用if判断一下其级别，保持一致的写法。

关于日志框架还有几句想说的，在公司的野蛮生长阶段，如果一些基础设施不做约束，会对未来埋下很多隐患，迟早要为此付出代价。而在Java里最搞的就是日志框架了，五花八门。之前在做应用容器的时候，为了解决上层各种日志框架的不一致，做了很多奇技淫巧来适配，非常痛苦。如果你在有能力控制的时候一定要尽早控制。

btw，我们当前使用的日志框架是logback，完全满足当前的需求。尽管log4j2前段时间终于发布了，也看到它的一个性能比logback有很大提升，但它的异步实现是基于LMAX的Disruptor，引入这个库似乎过重，像是专门为当前流行的大数据业务所设计；等真的遇到吞吐问题再去考虑它吧。