Java读取Level-1行情dbf文件极致优化（2）

最近架构一个项目，实现行情的接入和分发，须要达到极致的低时延特性，这对于证券系统是很是重要的。接入的行情源是能够配置，既能够是Level-1，也能够是Level-2或其余第三方的源。虽然Level-1行情没有Level-2快，可是做为系统支持的行情源，咱们仍是须要优化它，使得从文件读取，到用户经过socket收到行情，端到端的时延尽量的低。本文主要介绍对level-1行情dbf文件读取的极致优化方案。相信对其余的dbf文件读取应该也有借鉴意义。

Level-1行情是由行情小站，定时每隔几秒把dbf文件（上海是show2003.dbf，深圳是sjshq.dbf）更新一遍，用新的行情替换掉旧的。咱们的目标就是，在新文件完成更新后，在最短期内将文件读取到内存，把每一行转化为对象，把每一个列转化为对应的数据类型。

咱们一共采用了6种优化方式。

 

咱们在上文《Java读取Level-1行情dbf文件极致优化（1）》中，介绍了2种咱们使用的优化策略：

优化一：采用内存硬盘（RamDisk）

优化二：采用JNotify，用通知替代轮询

 

本文继续介绍：

 

优化三：采用NIO读取文件

对于Dbf文件的读写，有许多的开源的实现，选择和改进它们是这里的重要策略。

 

有许多Dbf库是基于流的I/O实现的，即InputStream和OutStream。咱们应该采用NIO的方式，即基于RandomAccessFile，FileChannel和ByteBuffer。流的方式是一边处理数据，一边从文件中读取，而采用NIO能够一次性把整个文件加载到内存中。有测试代表（见《Java程序性能优化》一书），NIO的方式大概比流的方式快5倍左右。我这里提供采用NIO实现的dbf读取库供你们下载学习（最原始的出处已不可考了。这个代码被改写了，其中也已经包含我以后将要提出的优化策略），若是你的项目已经有dbf库，建议基于本文的优化策略进行改进，而不是直接替换为我提供的。

DBFReader库

 

其中，DBFReader.java中有以下代码片断：

建立FileChannel代码为：

this.dbf = new RandomAccessFile(file, "r");
this.fc = dbf.getChannel();

 

把指定的文件片断加载到ByteBuffer的代码为

private ByteBuffer loadData(int offset, int length) throws IOException {
        // return fc.map(MapMode.READ_ONLY, offset, length).load();
        ByteBuffer b = ByteBuffer.allocateDirect(length);
        fc.position(offset);
        fc.read(b);
        b.rewind();
        return b;

    }

 

以上，咱们使用ByteBuffer.allocateDirect(length)建立ByteBuffer。 allocateDirect方法建立的是DirectBuffer，DirectBuffer分配在”内核缓存区”，比普通的ByteBuffer快一倍，这也有利于咱们程序的优化。可是DirectBuffer的建立和销毁更耗时，在咱们接下来的优化中将要解决这一问题。

（我不打算详细介绍NIO的相关知识（可能我也讲不清楚），也不打算详细介绍DbfReader.java的代码，只重点讲解和性能相关的部分，接下来也是如此。）

 

优化四：减小读取文件时内存反复分配和GC

以上我提供的DBFReader.java文件读取的文件的基本步骤是 ：

1，把整个文件（除了文件头）读取到ByteBuffer当中（其实为DirectBuffer）

2，再把每一行从ByteBuffer读取到一个个byte[]数组中。

3，把这些byte[]数组封装在一个一个Record对象中（Record对象提供了从byte[]中读取列的各类方法）。

见如下loadRecordsWithOutDel方法：

private List<Record> loadRecordsWithOutDel() throws IOException {

        ByteBuffer bb = loadData(getDataIndex(), getCount() * getRecordLength());

        List<Record> rds = new ArrayList<Record>(getCount());
        for (int i = 0; i < getCount(); i++) {
            byte[] b = new byte[getRecordLength()];
            bb.get(b);

            if ((char) b[0] != '*') {
                Record r = new Record(b);
                rds.add(r);
            }
        }

        bb.clear();

        return rds;
    }

 

private ByteBuffer loadData(int offset, int length) throws IOException {
        // return fc.map(MapMode.READ_ONLY, offset, length).load();
        ByteBuffer b = ByteBuffer.allocateDirect(length);
        fc.position(offset);
        fc.read(b);
        b.rewind();
        return b;

    }

 

考虑到咱们系统的实际应用的状况：行情dbf文件每隔几秒就会刷新一遍，刷新后的大小基本上差很少，格式是彻底同样的，每行的大小是同样的。

 

注意看以上代码中高亮的部分，会反复建立ByteBuffer和byte数组。在咱们的应用场景下，彻底可使用一种缓存机制来重复使用他们，避免反复建立。要知道一个行情文件有5000多行之多，避免如此之多的new和GC，确定对性能有好处。

 

我添加了一个CacheManager类来完成这个工做：

import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.List;

public class CacheManager {
    
    private ByteBuffer byteBuffer = null;
    private int bufSize = 0;
    
    private List<byte[]> byteArrayList = null;
    private int bytesSize = 0;
    
    public CacheManager()
    {
    }
    
    public ByteBuffer getByteBuffer(int size)
    {
        if(this.bufSize < size)
        {
            byteBuffer = ByteBuffer.allocateDirect(size + 1024*8); //多分配一些，避免下次从新分配
            this.bufSize = size + 1024*8;
        }
        byteBuffer.clear();
        return byteBuffer;
    }
    
    public List<byte[]> getByteArrayList(int rowNum, int byteLength) //rowNum为行数，即须要的byte[]数量，byteLength为byte数组的大小 
    {
        if(this.bytesSize!=byteLength)
        {
            byteArrayList = new ArrayList<byte[]>();
            this.bytesSize = byteLength;
        }
        
        if(byteArrayList.size() < rowNum)
        {
            int shouldAddRowCount = rowNum - byteArrayList.size()+100; //多分配100行
            for(int i=0; i<shouldAddRowCount; i++) 
            {
                byteArrayList.add(new byte[bytesSize]);
            }
        }
        
        return byteArrayList;
    }
    
}

 

CacheManager 管理了一个能够反复使用的ByteBuffer，以及能够反复使用的byte[]列表。

 

其中，getByteBuffer方法用于返回一个缓存的ByteBuffer。其只有当缓存的ByteBuffer小于指定的大小时，才从新建立ByteBuffer。（为了尽可能避免这种状况，咱们老是分配比实际须要大一些的ByteBuffer）。

 

其中，getByteArrayList方法用于返回缓存的byte[]列表。其只有当须要的Byte[]数量小于须要的数量时，建立更多的byte[]； 若是缓存的byte[]们的长度和须要的不符，就从新建立全部的byte[]（这种状况不可能发生，由于每行的大小不会变，代码只是以防万一而已）。

 

将loadRecordsWithOutDel改造为recordsWithOutDel_efficiently，采用缓存机制：

public List<byte[]> recordsWithOutDel_efficiently(CacheManager cacheManager) throws IOException {

        ByteBuffer bb = cacheManager.getByteBuffer(getCount() * getRecordLength());
        fc.position(getDataIndex());
        fc.read(bb);
        bb.rewind();
        List<byte[]> rds = new ArrayList<byte[]>(getCount());
        List<byte[]> byteArrayList = cacheManager.getByteArrayList(getCount(), getRecordLength());
        for (int i = 0; i < getCount(); i++) {
            byte[] b = byteArrayList.get(i);
            bb.get(b);

            if ((char) b[0] != '*') {
                rds.add(b);
            }
        }

        bb.clear();
        return rds;
    }

 

在新的recordsWithOutDel_efficiently中，咱们从CacheManager中分配缓存的ByteBuffer和缓存的byte[]。而不是从系统分配，从而减小了反复的内存分配和GC。（另外，recordsWithOutDel_efficiently直接返回byte[]列表，而不是Record列表了）

 

个人测试发现，优化步骤四，即便用缓存的方式，大概把时间从5ms左右降到了2ms多，提升大概一倍。

 

到此，咱们只是完成了文件到内存的读取。接着是为每一行建立一个行情对象，从byte[]中把每一列数据读取出来。  我发现，其耗时远远超过文件读取，在没有优化的状况下，对5000多行数据的转换超过70ms。这是咱们接下来须要介绍的优化策略。

 

待续。。。

 

 

Binhua Liu原创文章，转载请注明原地址http://www.cnblogs.com/Binhua-Liu/p/5615299.html