BlogJava-上善若水-随笔分类-CodeTools

实现自己的Lock对象

DLevin — Mon, 10 Aug 2015 22:08:00 GMT

一直想好好学习concurrent包中的各个类的实现，然而经常看了一点就因为其他事情干扰而放下了。发现这样太不利于自己的成长了，因而最近打算潜心一件一件的完成自己想学习的东西。

对concurrent包的学习打算先从Lock的实现开始，因而自然而然的就端起了AbstractQueuedSynchronizer，然而要读懂这个类的源码并不是那么容易，因而我就开始问自己一个问题：如果自己要去实现这个一个Lock对象，应该如何实现呢？

要实现Lock对象，首先理解什么是锁？我自己从编程角度简单的理解，所谓锁对象（互斥锁）就是它能保证一次只有一个线程能进入它保护的临界区，如果有一个线程已经拿到锁对象，那么其他对象必须让权等待，而在该线程退出这个临界区时需要唤醒等待列表中的其他线程。更学术一些，《计算机操作系统》中对同步机制准则的归纳（P50）：

空闲让进。当无进程处于临界区时，表明临界资源处于空闲状态，应允许一个请求进入临界区的进程立即进入自己的临界区，以有效的利用临界资源。
忙则等待。当已有进程进入临界区时，表明临界资源正在被访问，因而其他试图进入临界区的进程必须等待，以保证对临界区资源的互斥访问。
有限等待。对要求访问临界资源的进程，应保证在有限时间内能进入自己的临界区，以免陷入“死等”状态。
让权等待。当进程不能进入自己的临界区时，应该释放处理机，以免进程陷入“忙等”状态。

说了那么多，其实对互斥锁很简单，只需要一个标记位，如果该标记位为0，表示没有被占用，因而直接获得锁，然后把该标记位置为1，此时其他线程发现该标记位已经是1，因而需要等待。这里对这个标记位的比较并设值必须是原子操作，而在JDK5以后提供的atomic包里的工具类可以很方便的提供这个原子操作。然而上面的四个准则应该漏了一点，即释放锁的线程（进程）和得到锁的线程（进程）应该是同一个，就像一把钥匙对应一把锁（理想的），所以一个非常简单的Lock类可以这么实现：

public class SpinLockV1 {
    private final AtomicInteger state = new AtomicInteger(0);
    private volatile Thread owner; // 这里owner字段可能存在中间值，不可靠，因而其他线程不可以依赖这个字段的值

    public void lock() {
        while (!state.compareAndSet(0, 1)) { }
        owner = Thread.currentThread();
    }

    public void unlock() {
        Thread currentThread = Thread.currentThread();
        if (owner != currentThread || !state.compareAndSet(1, 0)) {
            throw new IllegalStateException("The lock is not owned by thread: " + currentThread);
        }
        owner = null;
    }
}

一个简单的测试方法：

    @Test
    public void testLockCorrectly() throws InterruptedException {
        final int COUNT = 100;
        Thread[] threads = new Thread[COUNT];
        SpinLockV1 lock = new SpinLockV1();
        AddRunner runner = new AddRunner(lock);
        for (int i = 0; i < COUNT; i++) {
            threads[i] = new Thread(runner, "thread-" + i);
            threads[i].start();
        }

        for (int i = 0; i < COUNT; i++) {
            threads[i].join();
        }

        assertEquals(COUNT, runner.getState());
    }

    private static class AddRunner implements Runnable {
        private final SpinLockV1 lock;
        private int state = 0;

        public AddRunner(SpinLockV1 lock) {
            this.lock = lock;
        }

        public void run() {
            lock.lock();
            try {
                quietSleep(10);
                state++;
                System.out.println(Thread.currentThread().getName() + ": " + state);
            } finally {
                lock.unlock();
            }
        }

        public int getState() {
            return state;
        }
    }

然而这个SpinLock其实并不需要state这个字段，因为owner的赋值与否也是一种状态，因而可以用它作为一种互斥状态：

public class SpinLockV2 {
    private final AtomicReference<Thread> owner = new AtomicReference<Thread>(null);

    public void lock() {
        final Thread currentThread = Thread.currentThread();
        while (!owner.compareAndSet(null, currentThread)) { }
    }

    public void unlock() {
        Thread currentThread = Thread.currentThread();
        if (!owner.compareAndSet(currentThread, null)) {
            throw new IllegalStateException("The lock is not owned by thread: " + currentThread);
        }
    }
}

这在操作系统中被定义为整形信号量，然而整形信号量如果没拿到锁会一直处于“忙等”状态（没有遵循有限等待和让权等待的准则），因而这种锁也叫Spin Lock，在短暂的等待中它可以提升性能，因为可以减少线程的切换，concurrent包中的Atomic大部分都采用这种机制实现，然而如果需要长时间的等待，“忙等”会占用不必要的CPU时间，从而性能会变的很差，这个时候就需要将没有拿到锁的线程放到等待列表中，这种方式在操作系统中也叫记录型信号量，它遵循了让权等待准则（当前没有实现有限等待准则）。在JDK6以后提供了LockSupport.park()/LockSupport.unpark()操作，可以将当前线程放入一个等待列表或将一个线程从这个等待列表中唤醒。然而这个park/unpark的等待列表是一个全局的等待列表，在unpartk的时候还是需要提供需要唤醒的Thread对象，因而我们需要维护自己的等待列表，但是如果我们可以用JDK提供的工具类ConcurrentLinkedQueue，就非常容易实现，如LockSupport文档中给出来的代码事例：

class FIFOMutex {
   private final AtomicBoolean locked = new AtomicBoolean(false);
   private final Queue<Thread> waiters = new ConcurrentLinkedQueue<Thread>();

   public void lock() {
     boolean wasInterrupted = false;
     Thread current = Thread.currentThread();
     waiters.add(current);

     // Block while not first in queue or cannot acquire lock
     while (waiters.peek() != current || !locked.compareAndSet(false, true)) {
        LockSupport.park(this);
        if (Thread.interrupted()) // ignore interrupts while waiting
          wasInterrupted = true;
     }

     waiters.remove();
     if (wasInterrupted)          // reassert interrupt status on exit
        current.interrupt();
   }

   public void unlock() {
     locked.set(false);
     LockSupport.unpark(waiters.peek());
   }
}

在该代码事例中，有一个线程等待队列和锁标记字段，每次调用lock时先将当前线程放入这个等待队列中，然后拿出队列头线程对象，如果该线程对象正好是当前线程，并且成功使用CAS方式设置locked字段（这里需要两个同时满足，因为可能出现一个线程已经从队列中移除了但还没有unlock，此时另一个线程调用lock方法，此时队列头的线程就是第二个线程，然而由于第一个线程还没有unlock或者正在unlock，因而需要使用CAS原子操作来判断是否要park），表示该线程竞争成功，获得锁，否则将当前线程park，这里之所以要放在 while循环中，因为park操作可能无理由返回(spuriously)，如文档中给出的描述：

LockSupport.park()

public static void park(Object blocker)

Disables the current thread for thread scheduling purposes unless the permit is available.

If the permit is available then it is consumed and the call returns immediately; otherwise the current thread becomes disabled for thread scheduling purposes and lies dormant until one of three things happens:

Some other thread invokes unpark with the current thread as the target; or
Some other thread interrupts the current thread; or
The call spuriously (that is, for no reason) returns.

This method does not report which of these caused the method to return. Callers should re-check the conditions which caused the thread to park in the first place. Callers may also determine, for example, the interrupt status of the thread upon return.

Parameters:: blocker - the synchronization object responsible for this thread parking
Since:: 1.6

我在实现自己的类时就被这个“无理由返回”坑了好久。对于已经获得锁的线程，将该线程从等待队列中移除，这里由于ConcurrentLinkedQueue是线程安全的，因而能保证每次都是队列头的线程得到锁，因而在得到锁匙将队列头移除。unlock逻辑比较简单，只需要将locked字段打开（设置为false），唤醒（unpark）队列头的线程即可，然后该线程会继续在lock方法的while循环中继续竞争unlocked字段，并将它自己从线程队列中移除表示获得锁成功。当然安全起见，最好在unlock中加入一些验证逻辑，如解锁的线程和加锁的线程需要相同。

然而本文的目的是自己实现一个Lock对象，即只使用一些基本的操作，而不使用JDK提供的Atomic类和ConcurrentLinkedQueue。类似的首先我们也需要一个队列存放等待线程队列（公平起见，使用先进先出队列），因而先定义一个Node对象用以构成这个队列：

    protected static class Node {
        volatile Thread owner;
        volatile Node prev;
        volatile Node next;

        public Node(Thread owner) {
            this.owner = owner;
            this.state = INIT;
        }

        public Node() {
            this(Thread.currentThread());
        }
    }

简单起见，队列头是一个起点的placeholder，每个调用lock的线程都先将自己竞争放入这个队列尾，每个队列头后一个线程（Node）即是获得锁的线程，所以我们需要有head Node字段用以快速获取队列头的后一个Node，而tail Node字段用来快速插入新的Node，所以关键在于如何线程安全的构建这个队列，方法还是一样的，使用CAS操作，即CAS方法将自己设置成tail值，然后重新构建这个列表：

    protected boolean enqueue(Node node) {
        while (true) {
            final Node preTail = tail;
            node.prev = preTail;
            if (compareAndSetTail(preTail, node)) {
                preTail.next = node;
                return node.prev == head;
            }
        }
    }

在当前线程Node以线程安全的方式放入这个队列后，lock实现相对就比较简单了，如果当前Node是的前驱是head，该线程获得锁，否则park当前线程，处理park无理由返回的问题，因而将park放入while循环中（该实现是一个不可重入的实现）：

    public void lock() {
        // Put the latest node to a queue first, then check if the it is the first node
        // this way, the list is the only shared resource to deal with
        Node node = new Node();
        if (enqueue(node)) {
            current = node.owner;
        } else {
            while (node.prev != head) {
                LockSupport.park(this); // This may return "spuriously"!!, so put it to while
            }
            current = node.owner;
        }
    }

unlock的实现需要考虑多种情况，如果当前Node(head.next)有后驱，那么直接unpark该后驱即可；如果没有，表示当前已经没有其他线程在等待队列中，然而在这个判断过程中可能会有其他线程进入，因而需要用CAS的方式设置tail，如果设置失败，表示此时有其他线程进入，因而需要将该新进入的线程unpark从而该新进入的线程在调用park后可以立即返回（这里的CAS和enqueue的CAS都是对tail操作，因而能保证状态一致）：

    public void unlock() {
        Node curNode = unlockValidate();
        Node next = curNode.next;
        if (next != null) {
            head.next = next;
            next.prev = head;
            LockSupport.unpark(next.owner);
        } else {
            if (!compareAndSetTail(curNode, head)) {
                while (curNode.next == null) { } // Wait until the next available
                // Another node queued during the time, so we have to unlock that, or else, this node can never unparked
                unlock();
            } else {
                compareAndSetNext(head, curNode, null); // Still use CAS here as the head.next may already been changed
            }
        }
    }

具体的代码和测试类可以参考查看这里。

其实直到自己写完这个类后才直到者其实这是一个MCS锁的变种，因而这个实现每个线程park在自身对应的node上，而由前一个线程unpark它；而AbstractQueuedSynchronizer是CLH锁，因为它的park由前驱状态决定，虽然它也是由前一个线程unpark它。具体可以参考这里。

DLevin 2015-08-11 06:08 发表评论

ReferenceCountSet无锁实现

DLevin — Fri, 05 Dec 2014 16:29:00 GMT

摘要: 记得很久以前有一次面试被问到如何编写无锁程序，我当时觉得那个面试官脑子进水了，我们确实可以在某些情况下减少锁的使用，但是怎么可能避免呢？当然我现在还是持这种观点，在Java中，你可以有很多方法减少锁的使用(至少在你自己的代码中看起来)： 1. 比如常见的可以使用volatile关键字来保证某个字段在一个线程中的更新对其他线程的可见性； 2.&nb... 阅读全文

DLevin 2014-12-06 00:29 发表评论

Java Cache系列之Cache概述和Simple Cache

DLevin — Tue, 15 Oct 2013 15:46:00 GMT

前记：最近公司在做的项目完全基于Cache（Gemfire）构建了一个类数据库的系统，自己做的一个小项目里用过Guava的Cache，以前做过的项目中使用过EHCache，既然和Cache那么有缘，那就趁这个机会好好研究一下Java中的Cache库。在Java社区中已经提供了很多Cache库实现，具体可以参考http://www.open-open.com/13.htm，这里只关注自己用到的几个Cache库而且这几个库都比较具有代表性：Guava中提供的Cache是基于单JVM的简单实现；EHCache出自Hibernate，也是基于单JVM的实现，是对单JVM Cache比较完善的实现；而Gemfire则提供了对分布式Cache的完善实现。这一系列的文章主要关注在这几个Cache系统的实现上，因而步探讨关于Cache的好处、何时用Cache等问题，由于他们都是基于内存的Cache，因而也仅局限于这种类型的Cache（说实话，我不知道有没有其他的Cache系统，比如基于文件？囧）。

记得我最早接触Cache是在大学学计算机组成原理的时候，由于CPU的速度要远大于内存的读取速度，为了提高CPU的效率，CPU会在内部提供缓存区，该缓存区的读取速度和CPU的处理速度类似，CPU可以直接从缓存区中读取数据，从而解决CPU的处理速度和内存读取速度不匹配的问题。缓存之所以能解决这个问题是基于程序的局部性原理，即”程序在执行时呈现出局部性规律，即在一段时间内，整个程序的执行仅限于程序中的某一部分。相应地，执行所访问的存储空间也局限于某个内存区域。局部性原理又表现为：时间局部性和空间局部性。时间局部性是指如果程序中的某条指令一旦执行，则不久之后该指令可能再次被执行；如果某数据被访问，则不久之后该数据可能再次被访问。空间局部性是指一旦程序访问了某个存储单元，则不久之后。其附近的存储单元也将被访问。”在实际工作中，CPU先向缓存区读取数据，如果缓存区已存在，则读取缓存中的数据（命中），否则（失效），将内存中相应数据块载入缓存中，以提高接下来的访问速度。由于成本和CPU大小的限制，CPU只能提供有限的缓存区，因而缓存区的大小是衡量CPU性能的重要指标之一。

使用缓存，在CPU向内存更新数据时需要处理一个问题（写回策略问题），即CPU在更新数据时只更新缓存的数据（write back，写回，当缓存需要被替换时才将缓存中更新的值写回内存），还是CPU在更新数据时同时更新缓存中和内存中的数据（write through，写通）。在写回策略中，为了减少内存写操作，缓存块通常还设有一个脏位（dirty bit），用以标识该块在被载入之后是否发生过更新。如果一个缓存块在被置换回内存之前从未被写入过，则可以免去回写操作；写回的优点是节省了大量的写操作。这主要是因为，对一个数据块内不同单元的更新仅需一次写操作即可完成。这种内存带宽上的节省进一步降低了能耗，因此颇适用于嵌入式系统。写通策略由于要经常和内存交互（有些CPU设计会在中间提供写缓冲器以缓解性能），因而性能较差，但是它实现简单，而且能简单的维持数据一致性。

在软件的缓存系统中，一般是为了解决内存的访问速率和磁盘、网络、数据库（属于磁盘或网络访问，单独列出来因为它的应用比较广泛）等访问速率不匹配的问题（对于内存缓存系统来说）。但是由于内存大小和成本的限制，我们又不能把所有的数据先加载进内存来。因而如CPU中的缓存，我们只能先将一部分数据保存在缓存中。此时，对于缓存，我们一般要解决如下需求：

使用给定Key从Cache中读取Value值。CPU是通过内存地址来定位内存已获取相应内存中的值，类似的在软件Cache中，需要通过某个Key值来标识相关的值。因而可以简单的认为软件中的Cache是一个存储键值对的Map，比如Gemfire中的Region就继承自Map，只是Cache的实现更加复杂。
当给定的Key在当前Cache不存在时，程序员可以通过指定相应的逻辑从其他源（如数据库、网络等源）中加载该Key对应的Value值，同时将该值返回。在CPU中，基于程序局部性原理，一般是默认的加载接下来的一段内存块，然而在软件中，不同的需求有不同的加载逻辑，因而需要用户自己指定对应的加载逻辑，而且一般来说也很难预知接下来要读取的数据，所以只能一次只加载一条纪录（对可预知的场景下当然可以批量加载数据，只是此时需要权衡当前操作的响应时间问题）。
可以向Cache中写入Key－Value键值对（新增的纪录或对原有的键值对的更新）。就像CPU的写回策略中有写回和写通策略，有些Cache系统提供了写通接口。如果没有提供写通接口，程序员需要额外的逻辑处理写通策略。也可以如CPU中的Cache一样，只当相应的键值对移出Cache以后，再将值写回到数据源，可以提供一个标记位以决定要不要写回（不过感觉这种实现比较复杂，代码的的耦合度也比较高，如果为提升写的速度，采用异步写回即可，为防止数据丢失，可以使用Queue来存储）。
将给定Key的键值对移出Cache（或给定多个Key以批量移除，甚至清除整个Cache）。
配置Cache的最大使用率，当Cache超过该使用率时，可配置溢出策略
1. 直接移除溢出的键值对。在移除时决定是否要写回已更新的数据到数据源。
2. 将溢出的溢出的键值对写到磁盘中。在写磁盘时需要解决如何序列化键值对，如何存储序列化后的数据到磁盘中，如何布局磁盘存储，如何解决磁盘碎片问题，如何从磁盘中找回相应的键值对，如何读取磁盘中的数据并方序列化，如何处理磁盘溢出等问题。
3. 在溢出策略中，除了如何处理溢出的键值对问题，还需要处理如何选择溢出的键值对问题。这有点类似内存的页面置换算法（其实内存也可以看作是对磁盘的Cache），一般使用的算法有：先进先出（FIFO）、最近最少使用（LRU）、最少使用（LFU）、Clock置换（类LRU）、工作集等算法。
对Cache中的键值对，可以配置其生存时间，以处理某些键值对在长时间不被使用，但是又没能溢出的问题（因为溢出策略的选择或者Cache没有到溢出阶段），以提前释放内存。
对某些特定的键值对，我们希望它能一直留在内存中不被溢出，有些Cache系统提供PIN配置（动态或静态），以确保该键值对不会被溢出。
提供Cache状态、命中率等统计信息，如磁盘大小、Cache大小、平均查询时间、每秒查询次数、内存命中次数、磁盘命中次数等信息。
提供注册Cache相关的事件处理器，如Cache的创建、Cache的销毁、一条键值对的添加、一条键值对的更新、键值对溢出等事件。
由于引入Cache的目的就是为了提升程序的读写性能，而且一般Cache都需要在多线程环境下工作，因而在实现时一般需要保证线程安全，以及提供高效的读写性能。

在Java中，Map是最简单的Cache，为了高效的在多线程环境中使用，可以使用ConcurrentHashMap，这也正是我之前参与的一个项目中最开始的实现（后来引入EHCache）。为了语意更加清晰、保持接口的简单，下面我实现了一个基于Map的最简单的Cache系统，用以演示Cache的基本使用方式。用户可以向它提供数据、查询数据、判断给定Key的存在性、移除给定的Key(s)、清除整个Cache等操作。以下是Cache的接口定义。

public interface Cache {
    public String getName();
    public V get(K key);
    public Mapextends K, ? extends V> getAll(Iteratorextends K> keys);
    public boolean isPresent(K key);
    public void put(K key, V value);
    public void putAll(Mapextends K, ? extends V> entries);
    public void invalidate(K key);
    public void invalidateAll(Iteratorextends K> keys);
    public void invalidateAll();
    public boolean isEmpty();
    public int size();
    public void clear();
    public Mapextends K, ? extends V> asMap();
}

这个简单的Cache实现只是对HashMap的封装，之所以选择HashMap而不是ConcurrentHashMap是因为在ConcurrentHashMap无法实现getAll()方法；并且这里所有的操作我都加锁了，因而也不需要ConcurrentHashMap来保证线程安全问题；为了提升性能，我使用了读写锁，以提升并发查询性能。因为代码比较简单，所以把所有代码都贴上了（懒得整理了。。。。）。

public class CacheImpl implements Cache {
    private final String name;
    private final HashMap cache;
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private final Lock readLock = lock.readLock();
    private final Lock writeLock = lock.writeLock();

    public CacheImpl(String name) {
        this.name = name;
        cache = new HashMap();
    }

    public CacheImpl(String name, int initialCapacity) {
        this.name = name;
        cache = new HashMap(initialCapacity);
    }

    public String getName() {
        return name;
    }

    public V get(K key) {
        readLock.lock();
        try {
            return cache.get(key);
        } finally {
            readLock.unlock();
        }
    }

    public Mapextends K, ? extends V> getAll(Iteratorextends K> keys) {
        readLock.lock();
        try {
            Map map = new HashMap();
            List noEntryKeys = new ArrayList();
            while(keys.hasNext()) {
                K key = keys.next();
                if(isPresent(key)) {
                    map.put(key, cache.get(key));
                } else {
                    noEntryKeys.add(key);
                }
            }

            if(!noEntryKeys.isEmpty()) {
                throw new CacheEntriesNotExistException(this, noEntryKeys);
            }

            return map;
        } finally {
            readLock.unlock();
        }
    }

    public boolean isPresent(K key) {
        readLock.lock();
        try {
            return cache.containsKey(key);
        } finally {
            readLock.unlock();
        }
    }

    public void put(K key, V value) {
        writeLock.lock();
        try {
            cache.put(key, value);
        } finally {
            writeLock.unlock();
        }
    }

    public void putAll(Mapextends K, ? extends V> entries) {
        writeLock.lock();
        try {
            cache.putAll(entries);
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidate(K key) {
        writeLock.lock();
        try {
            if(!isPresent(key)) {
                throw new CacheEntryNotExistsException(this, key);
            }
            cache.remove(key);
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidateAll(Iteratorextends K> keys) {
        writeLock.lock();
        try {
            List noEntryKeys = new ArrayList();
            while(keys.hasNext()) {
                K key = keys.next();
                if(!isPresent(key)) {
                    noEntryKeys.add(key);
                }
            }
            if(!noEntryKeys.isEmpty()) {
                throw new CacheEntriesNotExistException(this, noEntryKeys);
            }

            while(keys.hasNext()) {
                K key = keys.next();
                invalidate(key);
            }
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidateAll() {
        writeLock.lock();
        try {
            cache.clear();
        } finally {
            writeLock.unlock();
        }
    }

    public int size() {
        readLock.lock();
        try {
            return cache.size();
        } finally {
            readLock.unlock();
        }
    }

    public void clear() {
        writeLock.lock();
        try {
            cache.clear();
        } finally {
            writeLock.unlock();
        }
    }

    public Mapextends K, ? extends V> asMap() {
        readLock.lock();
        try {
            return new ConcurrentHashMap(cache);
        } finally {
            readLock.unlock();
        }
    }

    public boolean isEmpty() {
        readLock.lock();
        try {
            return cache.isEmpty();
        } finally {
            readLock.unlock();
        }
    }

}

其简单的使用用例如下：

@Test
    public void testCacheSimpleUsage() {
        Book uml = bookFactory.createUMLDistilled();
        Book derivatives = bookFactory.createDerivatives();

        String umlBookISBN = uml.getIsbn();
        String derivativesBookISBN = derivatives.getIsbn();

        Cache cache = cacheFactory.create("book-cache");
        cache.put(umlBookISBN, uml);
        cache.put(derivativesBookISBN, derivatives);

        Book fetchedBackUml = cache.get(umlBookISBN);
        System.out.println(fetchedBackUml);

        Book fetchedBackDerivatives = cache.get(derivativesBookISBN);
        System.out.println(fetchedBackDerivatives);
    }

DLevin 2013-10-15 23:46 发表评论

Map deserialize from String

DLevin — Tue, 20 Sep 2011 07:54:00 GMT

1public class MapDeserialize {
2    public static void main(String[] args) {
3        Map<String, String> map = new HashMap<String, String>();
4        map.put("key1", "value1");
5        map.put("key2", null);
6        map.put("key3", "");
7
8        System.out.println(map);
9
10        Map<String, String> emptyMap = new HashMap<String, String>();
11        System.out.println(emptyMap);
12
13        MapDeserialize deserialize = new MapDeserialize();
14        String str1 = "{key3=, key2=null, key1=value1}";
15        String str2 = "{}";
16        Map<String, String> map1 = deserialize.str2Map(str1);
17        System.out.println("map1: " + map1);
18        Map<String, String> map2 = deserialize.str2Map(str2);
19        System.out.println("map2: " + map2);
20    }
21
22    // We are assuming that the str is generated by map.toString(), so the str will be something like:
23    // '{key3=, key2=null, key1=value1}' or '{}'
24    public Map<String, String> str2Map(String str) {
25        Map<String, String> map = new HashMap<String, String>();
26        // The parameters map is empty
27        if("{}".equals(str) || str == null || str.length() == 0) {
28            return map;
29        }
30
31        // Remove the '{' prefix and '}' suffix
32        str = str.substring(1, str.length() - 1);
33        String[] entries = str.split(",");
34        for(String entry : entries) {
35            String[] pair = entry.split("=");
36            String key = pair[0].trim();
37            if(pair.length == 1) {
38                map.put(key, "");
39            } else {
40                String value = pair[1].trim();
41                if("null".equals(value)) {
42                    map.put(key, null);
43                } else {
44                    map.put(key, value);
45                }
46            }
47        }
48
49        return map;
50    }
51}

这段代码貌似没什么价值，只是保留着，以后再遇到相应的情况，可以再做改进。

DLevin 2011-09-20 15:54 发表评论

StopWatch类

DLevin — Fri, 08 Jul 2011 03:05:00 GMT

摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1/** *//** 2 * 在C#中提供了一个专门用于简单测试运行时间的类StopWatch， 3&nb... 阅读全文

DLevin 2011-07-08 11:05 发表评论