Java 8新特性探究-新犀牛
關(guān)于Nashorn的入門(mén)
主要是兩個(gè)方面,jjs工具以及javax.script包下面的API:
jjs是在java_home/bin下面自帶的,作為例子,讓我們創(chuàng)建一個(gè)func.js, 內(nèi)容如下:
1
2
|
function f() {return 1;};
print( f() + 1 );
|
運(yùn)行這個(gè)文件,把這個(gè)文件作為參數(shù)傳給jjs
1
|
jjs func.js
|
輸出結(jié)果:2
另一個(gè)方面是javax.script,也是以前Rhino余留下來(lái)的API
1
2
3
4
|
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName( "JavaScript" );
System.out.println( engine.getClass().getName() );
System.out.println( "Result:" + engine.eval( "function f() { return 1; }; f() + 1;" ) );
|
輸出如下:
jdk.nashorn.api.scripting.NashornScriptEngine
Result: 2
基本用法也可以去http://my.oschina.net/jsmagic/blog/212455 這篇博文參考一下;
Nashorn VS Rhino
javascript運(yùn)行在jvm已經(jīng)不是新鮮事了,Rhino早在jdk6的時(shí)候已經(jīng)存在,但現(xiàn)在為何要替代Rhino,官方的解釋是Rhino 相比其他javascript引擎(比如google的V8)實(shí)在太慢了,要改造Rhino還不如重寫(xiě)。既然性能是Nashorn的一個(gè)亮點(diǎn),下面就測(cè)試 下性能對(duì)比,為了對(duì)比兩者之間的性能,需要用到Esprima,一個(gè)ECMAScript解析框架,用它來(lái)解析未壓縮版的jquery(大約268kb),測(cè)試核心代碼如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
static void rhino(String parser, String code) {
String source = "speedtest";
int line = 1;
Context context = Context.enter();
context.setOptimizationLevel(9);
try {
Scriptable scope = context.initStandardObjects();
context.evaluateString(scope, parser, source, line, null);
ScriptableObject.putProperty(scope, "$code", Context.javaToJS(code, scope));
Object tree = new Object();
Object tokens = new Object();
for (int i = 0; i < RUNS; ++i) {
long start = System.nanoTime();
tree = context.evaluateString(scope, "esprima.parse($code)", source, line, null);
tokens = context.evaluateString(scope, "esprima.tokenize($code)", source, line, null);
long stop = System.nanoTime();
System.out.println("Run #" + (i + 1) + ": " + Math.round((stop - start) / 1e6) + " ms");
}
} finally {
Context.exit();
System.gc();
}
}
static void nashorn(String parser, String code) throws ScriptException,NoSuchMethodException {
ScriptEngineManager factory = new ScriptEngineManager();
ScriptEngine engine = factory.getEngineByName("nashorn");
engine.eval(parser);
Invocable inv = (Invocable) engine;
Object esprima = engine.get("esprima");
Object tree = new Object();
Object tokens = new Object();
for (int i = 0; i < RUNS; ++i) {
long start = System.nanoTime();
tree = inv.invokeMethod(esprima, "parse", code);
tokens = inv.invokeMethod(esprima, "tokenize", code);
long stop = System.nanoTime();
System.out.println("Run #" + (i + 1) + ": " + Math.round((stop - start) / 1e6) + " ms");
}
// System.out.println("Data is " + tokens.toString() + " and " + tree.toString());
}
|
從代碼可以看出,測(cè)試程序?qū)?zhí)行Esprima的parse和tokenize來(lái)運(yùn)行測(cè)試文件的內(nèi)容,Rhino和Nashorn分別執(zhí)行30次, 在開(kāi)始時(shí)候,Rhino需要1726 ms并且慢慢加速,最終穩(wěn)定在950ms左右,Nashorn卻有另一個(gè)特色,***次運(yùn)行耗時(shí)3682ms,但熱身后很快加速,最終每次運(yùn)行穩(wěn)定在 175ms,如下圖所示
nashorn首先編譯javascript代碼為java字節(jié)碼,然后運(yùn)行在jvm上,底層也是使用invokedynamic命令來(lái)執(zhí)行,所以運(yùn)行速度很給力。
為何要用java實(shí)現(xiàn)javascript
這也是大部分同學(xué)關(guān)注的點(diǎn),我認(rèn)同的觀點(diǎn)是:
-
成熟的GC
-
成熟的JIT編譯器
-
多線程支持
-
豐富的標(biāo)準(zhǔn)庫(kù)和第三方庫(kù)
總得來(lái)說(shuō),充分利用了java平臺(tái)的已有資源。
總結(jié)
新犀牛可以說(shuō)是犀牛式戰(zhàn)車(chē),比Rhino速度快了許多,作為高性能的javascript運(yùn)行環(huán)境,Nashorn有很多可能。
舉例, Avatar.js 是依賴(lài)于Nashorn用以支持在JVM上實(shí)現(xiàn)Node.js編程模型,另外還增加了其他新的功能,如使用一個(gè)內(nèi)建的負(fù)載平衡器實(shí)現(xiàn)多事件循環(huán),以及使用 多線程實(shí)現(xiàn)輕量消息傳遞機(jī)制;Avatar還提供了一個(gè)Model-Store, 基于JPA的純粹的JavaScript ORM框架。
在企業(yè)中另外一種借力 Nashorn方式是腳本,相比通常我們使用Linux等shell腳本,現(xiàn)在我們也可以使用Javascript腳本和Java交互了,甚至使用Nashorn通過(guò)REST接口來(lái)監(jiān)視服務(wù)器運(yùn)行狀況。