初始Vert.x

Vert.x框架最近比较火,它号称JVM上的Node.js。

http://vertx.io/

它目前支持JavaScript,Groovy,Ruby,Java,正在对Clojure,Scala,Python等。跟node.js一样,它是异步的、基于EDA的架构,跟Node.js一样,它拥有良好的并发及消息传递性能。

它支持HTTP/HTTPS,同时支持WebSockets,sockjs等高级协议。

其官方的benchmark相当漂亮:

Vert.x Benchmark


###event-driven模型

在vert.x内部,每一个vert.x实例称为一个verticle。verticle被bind到一个统一的event bus上,进行事件循环。其中一部分verticle是提供一些共享的lib(如共享的event handler),这种verticle被称为busmod。

通过event bus,Verticle可与运行在相同或不同vert.x实例中的其他verticle进行通信(基于Actor model)。

Vert.x verticle


###vert.x的线程模型

在vert.x中,每一个verticle(busmod)都被绑定到一个特殊的线程,所以在对verticle进行开发时,无需关注他的线程安全性。因此,对于vert.x instance,它管理着一个Thread Set,每个线程都维护了一个event loop。vert.x内部通过一个线程池,选择将一个event循环分配给具体的verticle。具体的线程响应模型采用了Reactor pattern

###内部实现

从其事件处理流程上很容易想到netty,vert.x在底层确实使用了netty。通过netty来处理高并发响应,reactor式的分派请求。vertx的ClusterManager基于Hazelcast进行轻量级实现。

具体细节还得看代码细节,有机会再分享https://github.com/vert-x/vert.x

简单的实现demo

1
2
3
4
5
6
7
8
9
Vertx vertx = Vertx .newVertx();
vertx.createHttpServer().requestHandler(
new Handler< HttpServerRequest>() {
public void handle(HttpServerRequest req) {
String file = req.path.equals( "/" ) ? "index.html"
: req.path;
req.response.sendFile( "webroot/" + file);
}
}).listen(8080);

DirectMemory源码分析

最近对cache相关进行了调研,看了一下off-heap cache DirectMemory源码,对其进行如下梳理:
源码路径:https://github.com/raffaeleguidi/DirectMemory

###引

Java cache通常的做法是通过缓存对象报错在heap,通过一定的持久化机制保存在disk。为了防止缓存对象被gc,通常用弱引用等wrap一下。

考虑到heap容量,缓存达到一定的容量必然会发生gc(full),由于full gc的STW,当heap容量达到10g以上时的pause time几乎是无法容忍的。

为了防止gc带来的性能问题,部分cache系统开始使用off-heap机制,通过对堆外内存的自主管理,防止额外的性能问题。这里面比较典型的是ehcache被terracotta收购后推出的BigMemory(http://www.ehcache.org/documentation/user-guide/bigmemory)

根据terracotta测试,BigMemory在350G+的场景下,表现良好。

由于BigMemory不开源,有个开源版的DirectMemory,实现跟其比较类似。

###DirectMemory

DirectMemory代码结构比较简单:

DirectMemory代码结构

下面结合其源码及数据的put操作,对其进行介绍:

####Cache

Cache作为入口,它通过ConcurrentMap 维护了String->Pointer,该Map的作用,后面会有介绍。该map通过google guava框架的MapMaker创建(可以方便的进行超时事件等)

Cache作为DirectMemory的入口,暴露了缓存操作的大部分接口,如put retrieve free等

需要指出的是,为了防止cache实例进入heap,cache的创建,属性同时通过static创建的。这也导致Cache在同一个JVM中是singleton的,无法根据需求创建多个cache

Cache层对对象的序列化是通过serialization包下的序列化器进行的,默认采用的是ProtoStuff。

下面是其put操作代码,从代码可以看到,Cache层主要通过调用memory包下的MemoryManager相应接口,进行cache的各种操作。同时操作后更新其本层Map

1
2
3
4
5
 public static Pointer putByteArray (String key, byte[] payload, int expiresIn) {
Pointer ptr = MemoryManager. store(payload, expiresIn);
map.put(key, ptr);
return ptr;
}


####MemoryManager

MemoryManager维护了

1
2
public static List<OffHeapMemoryBuffer> buffers = new Vector<OffHeapMemoryBuffer>();
public static OffHeapMemoryBuffer activeBuffer = null;

activeBuffer即为当前buffer,如果当前buffer满了,则跳到buffers的下一个buffer中,这些buffer在buffers中,很显然,通过对buffer的分片,可以较好的提高并发度。

下面的代码是MemoryManager进行store操作的过程,里面用很明显的逻辑进行了切(分)片操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
        public static Pointer store(byte[] payload, int expiresIn) {
Pointer p = activeBuffer .store(payload, expiresIn);
if (p == null) {
if (activeBuffer.bufferNumber+1 == buffers.size()) {
return null ;
} else {
// try next buffer
activeBuffer = buffers.get(activeBuffer.bufferNumber+1);
p = activeBuffer .store(payload, expiresIn);
}
}
return p;
}

MemoryManager中维持的Buffer是OffHeapMemoryBuffer。

####OffHeapMemoryBuffer

OffHeapMemoryBuffer是off-heap写入的核心组件,其核心为一个

1
protected ByteBuffer buffer ;

通过ByteBuffer.allocateDirect(capacity),生成的DirectByteBuffer。作为NIO提供的Buffer,它可以更高效的进行off-heap操作。

为了更高效的进行buffer读写,它提供了

1
public List<Pointer> pointers = new ArrayList<Pointer>();。

对于Pointer对象,其核心字段:

1
2
3
4
5
 public int start ;  //buffer的开始位置
public int end ; //buffer的结束位置
public boolean free ; //pointer是否可用
public int bufferNumber ; //所属的buffer number
.....

从本质上讲,它标识了一个buffer分片。通过将数据存储在这些细粒度分片上,可以更好的进行数据获取,并可以围绕key进行必要的操作,例如:Cache中包含一个key-Pointer的ConcurrentHashMap,这样在进行retrieve或update操作时,可以通过key先获得Pointer,然后可以通过pointer快速地对buffer进行操作。

初始化时,Pointer为buffer大小。每次store的时候,先查找是否有free的Pointer,如果存在,执行slice,将原来的pointer切分出一块数据大小的新的pointer,封装pointer属性,然后slice buffer,并忘buffer里写数据。同时将报错数据的pointer放入到pointers中。

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
private synchronized Pointer store(byte[] payload, long expiresIn, long expires) {
Pointer goodOne = firstMatch(payload. length);

if (goodOne == null ) {
throw new NullPointerException("did not find a suitable buffer");
}

Pointer fresh = slice(goodOne, payload. length);


fresh. created = System.currentTimeMillis();
if (expiresIn > 0) {
fresh. expiresIn = expiresIn;
fresh. expires = 0;
} else if (expires > 0) {
fresh. expiresIn = 0;
fresh. expires = expires;
}

fresh. free = false ;
used.addAndGet(payload.length );
ByteBuffer buf = buffer.slice();
buf.position(fresh. start);
try {
buf.put(payload);
} catch (BufferOverflowException e) {
// RpG not convincing - let's fix it later
goodOne. start = fresh.start ;
goodOne. end = buffer .limit();
return null ;
}
pointers.add(fresh);
return fresh;
}


###其他

  1. 从MemoryManager store操作代码可以看到,当store操作时,如果当前buffer空间不足时,直接进行换切片操作,显然如果数据非常大时,OffHeapMemoryBuffer存在空间浪费。同时纵观其代码,其内存管理比较粗,目前基本只涉及过期处理,LFU策略等。Pointer空间释放后,也没有必要的合并操作。内存空间浪费应该是个问题。
  2. key过期处理时,对Pointer进行查找时,在设计上采用了JoSQL框架,通过SQL方式获得Pointer,代码比较明晰。

伪共享

近期对并发编程进行了研究,看到已经从jsr166y添加到java 7里的LinkedTransferQueue及Disruptor框架均有对伪共享(False Sharing)问题进行了单独的处理,于是,对此类问题进行了梳理:

目前典型的CPU架构有三级缓存,从读取速度由快而慢分别为L1 -> L2 ->L3。对于多核架构,L1,L2为单核独享,而L3为多核共享。CPU指令执行即从L1 cache开始读取,如果cache miss,便从下一级cache读取,直到内存。

为了高效利用cache,CPU不是简单地将单条数据(指令)写入cache,而是将一批数据指令(连续地)写入cache行中。即cache行是对cache进行读写操作的最小单位。对于目前典型的core,ivy,sandy等cpu,cache行大小为64bytes。

同时,对于多核系统,每个核有私有的L1,L2,多线程并发时,如果某个核需要修改的变量同时在另外一个核的cache中,为了保证数据的一致性,需要使当前核cache中变量失效(invalidate),然后同步一致数据。这种操作是有硬件层级的缓存一致性协议来保证的,通常是M-E-S-I协议。其中M,E,S和I代表使用cache行所处的四个状态,协议通过四种状态的(复杂)迁移(类似状态机模型)来保证一致性。当发生上述不一致时,当前核会发出RFO(Request For Owner)请求来保证一致性,但是这个保证过程需要低层级cache或者内存的同步,会对性能造成很大的影响。
对于Java对象,相邻的成员变量被加载到同一个cache行中,当不同线程对成员变量分别操作时,就会导致RF0请求的发生,这种现象即伪共享。

Disruptor设计示意图

上图为disruptor作者设计的示意图,x,y变量分别被load到c1,c2的cache行中,c1更新x,c2更新y,而x,y位于同一条cache行中,此时两个线程轮番发送RFO消息,占有cache行拥有权,获得拥有权线程对变量的更新会导致其他核中的cache行中的变量失效,进而通过L3进行变量同步,而此时如果L3 miss,还需要通过内存同步,对性能造成很大的影响。因此,虽然x,y被独立线程操作,彼此无任何关系,因为伪共享,性能有很大的问题。
比较悲催的是,上面的x,y变量的伪共享在生产者-消费者模式中比较常见。生产者-消费者模式中,生产者和消费者作为不同的线程不停地操作队列的首尾两端(通过head,tail指针),而这两个指针对象定义在一起,加载head时,会将tail同时加载到同一个cache line中。

例如:Java j.u.c LinkedBlockingQueue的

1
2
3
4
5
 /** Head of linked list */
private transient Node<E> head;

/** Tail of linked list */
private transient Node<E> last;

head,last共占8bytes。两者被加载到同一个cache line。大量的生产者、消费者对queue进行读写时,会发生较大的性能问题

为了防止伪共享的发生,通常进行缓存行补齐(cache line padding),即对对象进行填充,使其占用一个cache行。这样可以保证对象不处于同一缓存行。

对于Hotspot Java对象,Java程序的对象头固定占8字节(32位系统),此时只需要填48bytes即可保证对象处于,不同的缓存行, 从而避免伪共享。(对于64位系统,对象头占用空间更大,多出也无所。)

例如:

在 LinkedTransferQueue中(早期的jsr166y版本,收录在早期的netty项目中),队列的head,tail如下定义:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/** head of the queue */
private final PaddedAtomicReference<QNode> head;
/** tail of the queue */
private final PaddedAtomicReference<QNode> tail;


/**
* Padded version of AtomicReference used for head, tail and
* cleanMe, to alleviate contention across threads CASing one vs
* the other.
*/

private static final class PaddedAtomicReference<T> extends AtomicReference<T> {
private static final long serialVersionUID = 4684288940772921317L;

// enough padding for 64bytes with 4byte refs
Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe;
PaddedAtomicReference(T r) { super(r); }
}

PaddedAtomicReference通过15个4byte对象,对AtomicReference进行了填充,从避免了伪共享,LinkedTransferQueue后期版本对其设计进行了更新,但核心类似,只是方法更加优雅(还没有完全看懂)。

在Disruptor框架中,其核心数据结构RingBuffer的序号由Sequence对象来维护,Sequence对象,定义了

1
private final long[] paddedValue = new long[15];

通过15个long来填充。序号设置/获取时分别调用

1
2
3
4
5
6
7
public long get(){
return unsafe.getLongVolatile(paddedValue, valueOffset);
}

public void set(final long value){
unsafe.putOrderedLong(paddedValue, valueOffset, value);
}

这样通过sun unsafe的CAS操作,对序号进行填充,从而避免了伪共享。

JAVA 7 G1收集器调研

最近在看虚拟机垃圾收集,看到了JAVA 7 G1收集器的相关内容,特深入调研了下。

G1收集器全称Garbage-First Garbage Collector。是在Java 6 Update 14中引入,旨在取代CMS收集器的一种新型收集器。在Java 6中只是试验性的引入,因各种原因没有正式引入。Java 7开始,其被正式引入。

作为一个server-style回收器,其具有如下属性:

1. 并行和并发

众所周知,目前所有的GC(无论是serial,parallel及近年来广泛使用的CMS)均存在暂停时间问题,所谓的暂停时间是由于GC的“stop-the-world” 机制(这个机制简称STW,即,在执行垃圾收集算法时,Java应用程序的其他所有除了垃圾收集帮助器线程之外的线程都被挂起)。而G1 可以从最新的硬件中获得并行的能力。它能够使用所有可用的CPU(CPU多核,硬件多线程,等)来加速它的STW暂停时间。虽然其并行机制在CMS中已有了一定的实现(即周期性的进行并发标记[concurrent marking phase]),但G1采用了新的实现方式。

该机制与G1新的堆内存管理机制相关。与其他GC收集器不同,在G1中,对象的新生代和老一代上并没有在物理上分隔开,而是把一个连续的堆内存拆分成了几个相同大小的区域。新生对象和老对象都会被放在一系列可能不连续的区域中。之所以这样做,就是为了让G1可以更灵活地移动老对象所占用的资源给新的对象。G1中的内存收集会发生 “疏散暂停”,当内存从一系列区域开始回收时,这些区域所引用的对象会被疏散到另一些区域中,这样,会有一整块的内存来重新被申请(其思想跟垃圾收集算法中的复制算法很类似)。疏散会发生整个程序的暂停,但“疏散”这些内存可以被并行运行,这正是G1的并发阶段做的事情。

2. 分代处理

与其它的HotSpot 垃圾回收器一样,G1 也是分代的。即它在处理新分配的对象(年轻代)和已经生存了一段时间的对象(年老代)时会不同,它会更多地考虑一些新创建的对象实例,因为越新创建的就越有最大的可能性被回收,老对象只是偶尔访问一下。对于大多数的Java应用来说,这个机制可以极大地提高回收效率。

3. 紧凑内存(碎片整理

与CMS收集器不同,G1 会对堆进行内存整理。压缩可以消除潜在的内存碎片的问题,这样程序就可以更长时间的平滑运行。

4. 预见性

G1 比起 CMS 来有更多的预见性。这个主要还是用来消除内存碎片的问题。内存的碎片少了,STW的暂停时间也会被减少。

目前G1仍然还在试验阶段,使用下面两个参数可以打开G1机制:

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

目前G1收集器还存在如下问题:

  1. G1不支持 JVM TI JMX等工具,由于相当数量的JVM管理及监控工具都是基于这两个服务的,因此基于G1很多工具无法正确使用。
  2. G1不支持增量永生代收集。因此,在应用卸载类时,无法进行收集。
  3. STW的暂停时间不太稳定,与CMS相比,时好时坏。

It is running out

I think i’m drowning
asphyxiated
i wanna break this spell
that you’ve created

you’re something evil
a contradiction
i wanna finish the game
and kill the friction

But you will be the death of me
you are just the death of me

bury it
i wanna bury it
i wanna smother it
i wanna murder it

I hope it is running out
and I hope the time is running out

But I can’t push it underground
I can’t stop it screaming out

I wanted freedom
but I’m restricted
I tried to give it up
but I’m addicted

Maybe you know i’m trapped
sense of elation
I know you’ll never dream of
breaking this fixation

you will squeeze the life out of me
til it run out.

Find a home

Find A Home (New Forest Shaker)
              Delays

One more year of digging here
And we’re alight in heaven; we’re alight in heaven
If we bare the stones and stares
Then we’re alight in heaven, we’re alight in heaven,

Mother says to hold our tongues; we are the chosen ones,
And we answer to no one,

Same dream I’m always having,
Like shivering, shivering, shivering…

Find a home amongst the trees,
Bend your branches over me,
Find a home, defy the freeze,
Dance around the rosaries…

Faith alone must clear this snow
Or we’ll have doubted heaven; we’ll have doubted heaven
It’s finisterre for dancing bears
If we have doubted heaven; we have doubted heaven

Everyone I left behind, they think I left my mind under Mesmer, sola fide
Same dream I’m always having,
Like shivering, shivering, shivering…

Find a home amongst the trees,
Bend your branches over me,
Find a home; defy the freeze, and glow,

Find a home…

Oh I can row, I can row, I can row back home,
Or we can lay, we can lay, we can lay in Sway,

Exogenesis Symphony, Pt. 2 Cross-Pollination

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
package  music.album.the.resistance;

import foobar;
import last.fm;

/**
* 编程需要交流
* @author Muse
* @author Sukani
**/
public class Exogenesis Symphony, Pt. 2 Cross-Pollination {

public void sing() {
/*我们不受周围人的影响*/
Rise above the crowds;
/*我们的充满辐射的环境下工作*/
Wade through toxic clouds;
/*我们要打破欧美软件列强的垄断*/
Breach the outer sphere;
/*我们虽然没有把握, 但是相互交流或许能提高*/
The edge of all our fears rest with you;
/*我们需要交流!*/
We are counting on you;
/*我们需要交流!*/
It's up to you;
/*赶紧把代码共享出来!*/
Spread our codes to the stars;
/*交流才是王道*/
You must rescue us all;
/*赶紧把代码共享出来!*/
Spread our codes to the stars;
/*交流才是王道*/
You must rescue us all;
/*告诉大家*/
Tell us;
/*你这段代码倒是是干什么用的!*/
Tell us your final wish;
/*说不明白就别想回去!*/
Now we know you can never return;
/*告诉大家*/
Tell us;
/*你这段代码倒是是干什么用的!*/
Tell us your final wish;
/*我们要Open-Source, 与全球的同行分享!*/
We will tell it to the world;
}

public void afterSing() {
if (action.equals("闲的!")) {
System.out.println("也是被论文逼得.");
}
}

}

论文敲到了无力, 可是还是感觉没有尽头.

回头一望, 尽是些问题在遗留.


周围是辐射中的空气在走.

心也跟着在走.

只是走的漫无目的, 一愣神, 却发现那word文档已淹没在网页的最里头.

于是翻开文档任凭思绪游走.

大大小小的毕业经历了非奇即偶.

感觉随着时间的流走, 心也会变的坦然, 也会变的不那么手慌脚抖.

毕竟工作有了, 毕业时也不会有太多的离愁.


可时间在走, 心也在走.

而且心仿似走在了时间的前头.

可虽然心已走远, 情却还是留在时间的后头.

于是心在时间的尽头停留.

静静的看着它走.

静静地看着它走.

可它却不住的回头, 看的自己眉间布满了忧愁.

于是, 跟着它往回走.

走到了记忆的尽头.

看得抽搐的发抖.


终于, 心再也不能疾走.

只好看着时间默默泪流.


而情, 偷偷地藏在心头.

反方向的望着记忆幽幽.

望得泪流.

好的故事

好的故事》 Revised


天变得朦朦,在预告着夜已渐渐地深;身体越发的不行,早被连绵不绝的夜熏得很憔悴。公路的繁响在四近,过往的画面仿佛在眼前:是昏沉的夜。

我闭了眼睛,向后一仰,靠在椅背上;放开鼠标的手搁在膝髁上。

我在蒙胧中,看见一个好的故事。

这故事很美丽,幽雅,别致。许多美的人和美的事,错综起来像一天云锦,而且万颗奔星似的飞动着,同时又展开去,以至于无穷。

我仿佛记得跟她乘坐小船经过山阴小道,两岸边的青山, 乌桕,新禾,野花,茅屋,塔,伽蓝,人群,小鸟……都倒影在澄碧的小河中,随着船的前进,清水中夹带着闪烁的日光,并着水里的萍藻游鱼,一同荡漾。诸影诸物,无不解散,而且摇动,扩大,互相融和;刚一融和,却又退缩,复近于原形。边缘都参差如夏云头,镶着日光,发出水银色焰。凡是我所经过的河,都是如此。

现在我所见的故事也如此。水中的青天的底子,一切事物统在上面交错,织成一篇,永是生动,永是展开,我看不见这一篇的结束。

河边枯柳树下的几株瘦削的一丈红,是她做的。无边无际的红,都在水里面浮动,忽而碎散,拉长了,如缕缕的胭脂水,然而没有晕。周围的一切随之晃动。大红花一朵朵全被拉长了,这时是泼剌奔迸的红锦带。

霎那间, 水渐辉黄, 伴着微微的风荡漾, 我跟她看着天边的夕阳, 夕阳消失在辉煌。

现在我所见的故事清楚起来了,美丽,幽雅,别致,而且分明。青天上面,虽有有无数美的人和美的事,我一一看见,一一知道,到那时独此事,让我神往。

我要凝视他,凝视到天亮……。

我正要凝视他时,骤然一惊,睁开眼,云锦也已皱蹙,凌乱,仿佛有谁掷一块大石下河水中,水波陡然起立,将整篇的影子撕成片片了。我无意识地赶忙捏住几乎坠地的鼠标,眼前还剩着几点虹霓色的碎影。

我真爱这一篇好的故事,趁碎影还在,我要追回他,完成他,留下他。拿起了鼠标,整理好的键盘安安静静——何尝有一丝碎影,只见昏暗的灯光,我不在小船里了。

但我总记得见过这一篇好的故事,在昏沉的夜……。

二零一零年一月三十日

忆我朝,奠我朝

六月七,宛若剑一般,插入与抽出并重,世界皆血泪横流。

时光飞转十一载,斯年,懵懂半载,球性愚钝,仅记得仰角四十五度之红黄相见,及左胸口瞬间之悸动。懵懂间入五月,望中亚之荒凉,观南亚之靡费,不禁兴奋,以为仅一时兴起,不料它若一精灵般纠缠不清,赶不走,甩不掉,铭刻眉间,驻留永生。

悲或喜?纠结不清。

犹记得那天,九月之十三,渤海之巅。我朝天子誓言镇守金州绝不给波斯蛮贼留一寸生机。于是满朝亢奋,毕竟某臣在抽签之际大放豪言”斯战必八战七捷!”,豪言壮语冲天,不留半片余地。大战开始,气势汹涌,西贼不禁胆寒。我朝大将李明尤其凶猛,不但助战友范兄一臂之力,还自告奋勇,独步前场,立下奇功。天子臣子看在眼里,乐在心中,心想”老臣鞠躬尽瘁,卖官行贿,只为此日之光宗耀祖,观此战之状,不虚此生矣!”。于是,臣子小乐,将大乐。可西贼不乐,尤以马达维基亚大将为最。他虽身若侏儒,却动如脱兔,一拳两脚,竟把我将搞的昏头转向。”我朝危矣!”,乐抽了筋儿时,他不禁大呼。正所谓兵败如山倒,将糗糗一窝。没悬念,我朝溃败。

今后之岁月,每追忆过往,品味球道,此战总于我脑海怅惘,不因它曲折跌宕,只因它使我初次认识这片土地之战争之求生之道,而我朝兵将却未能悟道。

可道终究是道,轻而易举就能大彻大悟显然无所谓道,岁月辗转,战场反复,我朝自然悟道。我一直都这般以为。

转眼辗转至十月末,西西域有一弹丸之国来我朝进犯,之前我朝在西贼侵攘之际,国力尽衰,稍有不甚就有崩盘之险。一定程度上,此战乃命悬之战,一旦不胜,数年之辛劳不复。

此弹丸名曰卡塔尔,乃波斯湾西南小国,夏季四十又六度的气候,造就了其黝黑弱小的身躯,唯有遍野的黑油昭显其贵族本色。此时我朝媒体空前团结,打气之势遍野,我将,我卒亦摆开架势,尽显玩命之势,臣民望此盛状及其悲壮,不禁欣慰溢胸。开战之初,我朝气势如虹,早早确立了优势,众将喜上眉梢,尽显骄溢之势。于是,战局斗转,几番攻势之后,我朝优势竟无!于是躁上眉梢,我朝尽显疲态,战局不堪,气势一泻千里,卡贼趁势追击,竟完成致命一击。我朝玩儿完……

此战之溃败,彻底埋葬了我朝数年之辛劳,也粉碎了我数载之向往,从此我记住了卡塔尔,了解了我朝之现状。道乃身内之物,悟性需要高人之指引,戚教主虽饱读群书,可对西方之道资历尚浅。一旦偶遇高人必有人悟道。

于是我朝天子云游天下,寻求高人,在不列颠,他遇到了霍先生,据说此人俱毕生之力研读蹴鞠之道,常年云游四方,廉价传道,备受好评。于是双方一拍即合,霍先生是个实在人,深知受人钱财,替人消灾之真理,工作之始即卖命苦干,倍受好评。可高人多了就定有低人,我朝不幸,霍先生竟实为低人,斯人确有纶巾之才,却无沙场点兵之力。几番纠葛,我朝不堪。霍先生豁达,得知自己失势,爽快闪人。于是我朝又糜顿了数载。

天子愤,继续云游,竟偶遇另一云游之高人,此人江湖人称米半仙,尤通八卦博弈之术,实乃人尽皆知的高人。天子大喜,半仙亦大喜,双方互送秋波,并引出惊天之佳话。米半仙果然高人矣,他常置点兵于不顾,以快乐之道相授,众将快乐了,却不会作战了,我朝之战斗力随着时间之漂移不升反降。

天子不悦,推倒重来。于是米半仙没蜕变成全仙,继续云游,寻找云端。我朝天子则在阿姆斯特丹继续云游,这一游不要紧,竟遇到了江湖混子,汗先生。汗先生人如起名,作战时让敌方汗,指挥时让己方汗。于是,我方大汗,汗先生竟然让我朝在科威特小卒面前颜面扫地,奇耻大辱,天子不堪。

于是,汗先生被切掉汗腺,卷汗走人。天子郁闷,班师回朝。闲暇之余竟突生一想法,邀请朝内著名的猪老师沙场点兵。这位猪老师实乃不世之才,在职其间,开创耸人听闻”疯狗疗法”,并以其人脉之网络,广结党羽,甚至有一时间,风靡江湖的李毅大侠也甘愿为其甘当护卫。俗话说,人无完人,猪无完猪,猪老师即非完人亦非完猪,我朝在马来群岛混战中竟不力冲出东南亚,令人发指。

于是,人神公愤,猪老师被打会了动物界。天子郁闷之极,观九洲之贤士,无望。云游四方,天子圣明,此时塞族双贤进入视野。所谓双贤,意即双闲,至少福先生乃一大闲。双闲登基一载后,竟遇一流芳百世之机遇,一旦紧握,必成圣贤。此即六月七卡塔尔之难。

十一载之后,卡塔尔脱胎换骨,花重金令南美三侠为其卖命,体现着金钱皆粪土之真谛,显露着贵族奴隶主之本色。

可我朝不屑其贵族贱族与否。但凡生死之战,我朝必先在士气上压到对手,然后再而衰,衰而竭,令国民欲罢不能。于是此战必败。只是冥冥中有些不甘,想我朝之盛状,问心中之向往,无数臣民亦投注心血。于是心血变成鲜血,我朝遭遇空前绝后之惨状。

斯战惨烈,以致我不愿回忆。仅记得,我军被卡贼打的体无完肤,仅记的战前之豪言壮语皆扯淡。

于是,我看清真相,斩断臆想,尽生理之极致抛之云霄。悲与喜,区分一清。但若来年有此番,我心向何方?


回首当年,绮楼画阁生光彩。朝弹瑶瑟夜银筝,歌舞人潇洒。一自市朝更改。
暗销魂,繁华难再。金钗十二,珍履三千,凄凉千载!

《烛影摇红》,借着烛影,看清困厄之海市蜃楼;品着摇红,慢慢摇碎曾经之向往。
虽夏完淳之感时伤怀与此番相比略显不合时宜,可此时之心情与数百年前,古今一般同。


PS:郭林别餐归来,想我朝之失势,伤痛悼惜之中,觉心有不甘,独起凭栏对过往,唏嘘不已,凭跑步而卸闷,不料体力不堪,半死不活,痛不欲生,身心俱乏,以致心力憔悴,遂购花生以调节,嚼咬饕餮之余,顿感空荡,是为文。