Archive for 六月 2011

Java并发编程之ConcurrentHashMap

ConcurrentHashMap

ConcurrentHashMap是一个线程安全的Hash Table,它的主要功能是提供了一组和HashTable功能相同但是线程安全的方法。ConcurrentHashMap可以做到读取数据不加锁,并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小,不用对整个ConcurrentHashMap加锁。

ConcurrentHashMap的内部结构

ConcurrentHashMap为了提高本身的并发能力,在内部采用了一个叫做Segment的结构,一个Segment其实就是一个类Hash Table的结构,Segment内部维护了一个链表数组,我们用下面这一幅图来看下ConcurrentHashMap的内部结构:
图表1
从上面的结构我们可以了解到,ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作,第一次Hash定位到Segment,第二次Hash定位到元素所在的链表的头部,因此,这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长,但是带来的好处是写操作的时候可以只对元素所在的Segment进行加锁即可,不会影响到其他的Segment,这样,在最理想的情况下,ConcurrentHashMap可以最高同时支持Segment数量大小的写操作(刚好这些写操作都非常平均地分布在所有的Segment上),所以,通过这一种结构,ConcurrentHashMap的并发能力可以大大的提高。

Segment

我们再来具体了解一下Segment的数据结构:

    static final class Segment<K,V> extends ReentrantLock implements Serializable {
        transient volatile int count;
        transient int modCount;
        transient int threshold;
        transient volatile HashEntry<K,V>[] table;
        final float loadFactor;
    }

详细解释一下Segment里面的成员变量的意义:

  • count:Segment中元素的数量
  • modCount:对table的大小造成影响的操作的数量(比如put或者remove操作)
  • threshold:阈值,Segment里面元素的数量超过这个值依旧就会对Segment进行扩容
  • table:链表数组,数组中的每一个元素代表了一个链表的头部
  • loadFactor:负载因子,用于确定threshold

HashEntry

Segment中的元素是以HashEntry的形式存放在链表数组中的,看一下HashEntry的结构:

    static final class HashEntry<K,V> {
        final K key;
        final int hash;
        volatile V value;
        final HashEntry<K,V> next;
    }

可以看到HashEntry的一个特点,除了value以外,其他的几个变量都是final的,这样做是为了防止链表结构被破坏,出现ConcurrentModification的情况。

ConcurrentHashMap的初始化

下面我们来结合源代码来具体分析一下ConcurrentHashMap的实现,先看下初始化方法:

    public ConcurrentHashMap(int initialCapacity,
                             float loadFactor, int concurrencyLevel) {
        if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
            throw new IllegalArgumentException();

        if (concurrencyLevel > MAX_SEGMENTS)
            concurrencyLevel = MAX_SEGMENTS;

        // Find power-of-two sizes best matching arguments
        int sshift = 0;
        int ssize = 1;
        while (ssize < concurrencyLevel) {
            ++sshift;
            ssize <<= 1;
        }
        segmentShift = 32 - sshift;
        segmentMask = ssize - 1;
        this.segments = Segment.newArray(ssize);

        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        int c = initialCapacity / ssize;
        if (c * ssize < initialCapacity)
            ++c;
        int cap = 1;
        while (cap < c)
            cap <<= 1;

        for (int i = 0; i < this.segments.length; ++i)
            this.segments[i] = new Segment<K,V>(cap, loadFactor);
    }

CurrentHashMap的初始化一共有三个参数,一个initialCapacity,表示初始的容量,一个loadFactor,表示负载参数,最后一个是concurrentLevel,代表ConcurrentHashMap内部的Segment的数量,ConcurrentLevel一经指定,不可改变,后续如果ConcurrentHashMap的元素数量增加导致ConrruentHashMap需要扩容,ConcurrentHashMap不会增加Segment的数量,而只会增加Segment中链表数组的容量大小,这样的好处是扩容过程不需要对整个ConcurrentHashMap做rehash,而只需要对Segment里面的元素做一次rehash就可以了。

整个ConcurrentHashMap的初始化方法还是非常简单的,先是根据concurrentLevel来new出Segment,这里Segment的数量是不大于concurrentLevel的最大的2的指数,就是说Segment的数量永远是2的指数个,这样的好处是方便采用移位操作来进行hash,加快hash的过程。接下来就是根据intialCapacity确定Segment的容量的大小,每一个Segment的容量大小也是2的指数,同样使为了加快hash的过程。

这边需要特别注意一下两个变量,分别是segmentShift和segmentMask,这两个变量在后面将会起到很大的作用,假设构造函数确定了Segment的数量是2的n次方,那么segmentShift就等于32减去n,而segmentMask就等于2的n次方减一。

ConcurrentHashMap的get操作

前面提到过ConcurrentHashMap的get操作是不用加锁的,我们这里看一下其实现:

    public V get(Object key) {
        int hash = hash(key.hashCode());
        return segmentFor(hash).get(key, hash);
    }

看第三行,segmentFor这个函数用于确定操作应该在哪一个segment中进行,几乎对ConcurrentHashMap的所有操作都需要用到这个函数,我们看下这个函数的实现:

    final Segment<K,V> segmentFor(int hash) {
        return segments[(hash >>> segmentShift) & segmentMask];
    }

这个函数用了位操作来确定Segment,根据传入的hash值向右无符号右移segmentShift位,然后和segmentMask进行与操作,结合我们之前说的segmentShift和segmentMask的值,就可以得出以下结论:假设Segment的数量是2的n次方,根据元素的hash值的高n位就可以确定元素到底在哪一个Segment中。

在确定了需要在哪一个segment中进行操作以后,接下来的事情就是调用对应的Segment的get方法:

        V get(Object key, int hash) {
            if (count != 0) { // read-volatile
                HashEntry<K,V> e = getFirst(hash);
                while (e != null) {
                    if (e.hash == hash && key.equals(e.key)) {
                        V v = e.value;
                        if (v != null)
                            return v;
                        return readValueUnderLock(e); // recheck
                    }
                    e = e.next;
                }
            }
            return null;
        }

先看第二行代码,这里对count进行了一次判断,其中count表示Segment中元素的数量,我们可以来看一下count的定义:

transient volatile int count;

可以看到count是volatile的,实际上这里里面利用了volatile的语义:

对volatile字段的写入操作happens-before于每一个后续的同一个字段的读操作。

因为实际上put、remove等操作也会更新count的值,所以当竞争发生的时候,volatile的语义可以保证写操作在读操作之前,也就保证了写操作对后续的读操作都是可见的,这样后面get的后续操作就可以拿到完整的元素内容。

然后,在第三行,调用了getFirst()来取得链表的头部:

        HashEntry<K,V> getFirst(int hash) {
            HashEntry<K,V>[] tab = table;
            return tab[hash & (tab.length - 1)];
        }

同样,这里也是用位操作来确定链表的头部,hash值和HashTable的长度减一做与操作,最后的结果就是hash值的低n位,其中n是HashTable的长度以2为底的结果。

在确定了链表的头部以后,就可以对整个链表进行遍历,看第4行,取出key对应的value的值,如果拿出的value的值是null,则可能这个key,value对正在put的过程中,如果出现这种情况,那么就加锁来保证取出的value是完整的,如果不是null,则直接返回value。

ConcurrentHashMap的put操作

看完了get操作,再看下put操作,put操作的前面也是确定Segment的过程,这里不再赘述,直接看关键的segment的put方法:

        V put(K key, int hash, V value, boolean onlyIfAbsent) {
            lock();
            try {
                int c = count;
                if (c++ > threshold) // ensure capacity
                    rehash();
                HashEntry<K,V>[] tab = table;
                int index = hash & (tab.length - 1);
                HashEntry<K,V> first = tab[index];
                HashEntry<K,V> e = first;
                while (e != null && (e.hash != hash || !key.equals(e.key)))
                    e = e.next;

                V oldValue;
                if (e != null) {
                    oldValue = e.value;
                    if (!onlyIfAbsent)
                        e.value = value;
                }
                else {
                    oldValue = null;
                    ++modCount;
                    tab[index] = new HashEntry<K,V>(key, hash, first, value);
                    count = c; // write-volatile
                }
                return oldValue;
            } finally {
                unlock();
            }
        }

首先对Segment的put操作是加锁完成的,然后在第五行,如果Segment中元素的数量超过了阈值(由构造函数中的loadFactor算出)这需要进行对Segment扩容,并且要进行rehash,关于rehash的过程大家可以自己去了解,这里不详细讲了。

第8和第9行的操作就是getFirst的过程,确定链表头部的位置。

第11行这里的这个while循环是在链表中寻找和要put的元素相同key的元素,如果找到,就直接更新更新key的value,如果没有找到,则进入21行这里,生成一个新的HashEntry并且把它加到整个Segment的头部,然后再更新count的值。

ConcurrentHashMap的remove操作

Remove操作的前面一部分和前面的get和put操作一样,都是定位Segment的过程,然后再调用Segment的remove方法:

        V remove(Object key, int hash, Object value) {
            lock();
            try {
                int c = count - 1;
                HashEntry<K,V>[] tab = table;
                int index = hash & (tab.length - 1);
                HashEntry<K,V> first = tab[index];
                HashEntry<K,V> e = first;
                while (e != null && (e.hash != hash || !key.equals(e.key)))
                    e = e.next;

                V oldValue = null;
                if (e != null) {
                    V v = e.value;
                    if (value == null || value.equals(v)) {
                        oldValue = v;
                        // All entries following removed node can stay
                        // in list, but all preceding ones need to be
                        // cloned.
                        ++modCount;
                        HashEntry<K,V> newFirst = e.next;
                        for (HashEntry<K,V> p = first; p != e; p = p.next)
                            newFirst = new HashEntry<K,V>(p.key, p.hash,
                                                          newFirst, p.value);
                        tab[index] = newFirst;
                        count = c; // write-volatile
                    }
                }
                return oldValue;
            } finally {
                unlock();
            }
        }

首先remove操作也是确定需要删除的元素的位置,不过这里删除元素的方法不是简单地把待删除元素的前面的一个元素的next指向后面一个就完事了,我们之前已经说过HashEntry中的next是final的,一经赋值以后就不可修改,在定位到待删除元素的位置以后,程序就将待删除元素前面的那一些元素全部复制一遍,然后再一个一个重新接到链表上去,看一下下面这一幅图来了解这个过程:
1
假设链表中原来的元素如上图所示,现在要删除元素3,那么删除元素3以后的链表就如下图所示:
2

ConcurrentHashMap的size操作

在前面的章节中,我们涉及到的操作都是在单个Segment中进行的,但是ConcurrentHashMap有一些操作是在多个Segment中进行,比如size操作,ConcurrentHashMap的size操作也采用了一种比较巧的方式,来尽量避免对所有的Segment都加锁。

前面我们提到了一个Segment中的有一个modCount变量,代表的是对Segment中元素的数量造成影响的操作的次数,这个值只增不减,size操作就是遍历了两次Segment,每次记录Segment的modCount值,然后将两次的modCount进行比较,如果相同,则表示期间没有发生过写入操作,就将原先遍历的结果返回,如果不相同,则把这个过程再重复做一次,如果再不相同,则就需要将所有的Segment都锁住,然后一个一个遍历了,具体的实现大家可以看ConcurrentHashMap的源码,这里就不贴了。

Java并发编程J.U.C之Condition

在上一篇中,我们了解了下J.U.C的锁的获取与释放的过程,这个过程主要通过在A.Q.S中维持一个等待队列来实现,其中我们也提到了,在A.Q.S中除了一个等待队列之外,还有一个Condition队列,在了解Condition队列之前,先来看一下Condition是怎么回事:

The synchronizer framework provides a ConditionObject class for use by synchronizers that maintain exclusive synchronization and conform to the Lock interface. Any number of condition objects may be attached to a lock object, providing classic monitor-style await, signal, and signalAll operations, including those with timeouts, along with some inspection and monitoring methods.

上面的这一段内容摘自Doug Lea的AQS论文,从上面这一段话可以看出,Condition主要是为了在J.U.C框架中提供和Java传统的监视器风格的wait,notify和notifyAll方法类似的功能,那么先来解释一下这三个方法的作用:

  • Object.wait()方法:使当前线程释放Object上的监视器并且挂起,直到有另外的线程调用Object.notify()方法或者Object.notifyAll()方法唤醒当前线程,当被唤醒后,Object.wait()方法会尝试重新获取监视器,成功获取后继续往下执行。注意Object.wait()方法只有在当前线程持有Object的监视器的时候才能够调用,不然会抛出异常。
  • Object.notify()方法:用于唤醒另外一个调用了Object.wait()方法的线程,如果有多个都调用了Object.wait()方法,那么就会选择一个线程去notify(),具体选择哪一个和具体的实现有关,当前线程在调用Object.notify()方法以后会就释放Object的监视器,和wait()方法一样,Object.notify()方法只有在当前线程只有Object的监视器的时候才能够调用,不然就会抛出异常。
  • Object.notifyAll()方法:唤醒所有调用了Object.wait()方法的线程,如果有多个线程调用了Object.wait()方法,那么就会引发这些线程之间的竞争,最后谁成功获取到Object的监视器和具体的实现有关,当前线程在调用Object.notifyAll()方法以后会就释放Object的监视器,和wait()方法一样,Object.notifyAll()方法只有在当前线程只有Object的监视器的时候才能够调用,不然就会抛出异常。

那么Condition是如何实现wait,notify和notifyAll方法的功能呢?我们接下来看:

在Condition中,wait,notify和notifyAll方法分别对应了await,signal和signalAll方法,当然Condition也提供了超时的、不可被中断的await()方法,不过我们主要还是看一看await,notify和notifyAll的实现,先看await:

await方法:

        public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            Node node = addConditionWaiter();
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
                LockSupport.park(this);
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null)
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

整个await的过程如下:

  1. 在第2行处,如果当前线程被中断,则抛出中断异常。
  2. 在第4行处,将节点加入到Condition队列中去,这里如果lastWaiter是cancel状态,那么会把它踢出Condition队列。
  3. 在第5行处,调用tryRelease,释放当前线程的锁
  4. 在第7行处,判断节点是否在等待队列中(signal操作会将Node从Condition队列中拿出并且放入到等待队列中去),如果不在等待队列中了,就park当前线程,如果在,就退出循环,这个时候如果被中断,那么就退出循环
  5. 在第12行处,这个时候线程已经被signal()或者signalAll()操作给唤醒了,退出了4中的while循环,尝试再次获取锁,调用acquireQueued方法。

可以看到,这个await的操作过程和Object.wait()方法是一样,只不过await()采用了Condition队列的方式实现了Object.wait()的功能。

signal和signalAll方法:

在了解了await方法的实现以后,signal和signalAll方法的实现就相对简单了,先看看signal方法:

        public final void signal() {
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            Node first = firstWaiter;
            if (first != null)
                doSignal(first);
        }

这里先判断当前线程是否持有锁,如果没有持有,则抛出异常,然后判断整个condition队列是否为空,不为空则调用doSignal方法来唤醒线程,看看doSignal方法都干了一些什么:

        private void doSignal(Node first) {
            do {
                if ( (firstWaiter = first.nextWaiter) == null)
                    lastWaiter = null;
                first.nextWaiter = null;
            } while (!transferForSignal(first) &&
                     (first = firstWaiter) != null);
        }

这个while循环的作用就是将firstWaiter往Condition队列的后面移一位,并且唤醒first,看看while循环中tranferForSignal:

    final boolean transferForSignal(Node node) {
        /*
         * If cannot change waitStatus, the node has been cancelled.
         */
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
            return false;

        /*
         * Splice onto queue and try to set waitStatus of predecessor to
         * indicate that thread is (probably) waiting. If cancelled or
         * attempt to set waitStatus fails, wake up to resync (in which
         * case the waitStatus can be transiently and harmlessly wrong).
         */
        Node p = enq(node);
        int c = p.waitStatus;
        if (c > 0 || !compareAndSetWaitStatus(p, c, Node.SIGNAL))
            LockSupport.unpark(node.thread);
        return true;
    }

这段代码的作用就是修改Node的waitStatus为0,然后将Node插入到等待队列中,并且唤醒Node。

signalAll和signal方法类似,主要的不同在于它不是调用doSignal方法,而是调用doSignalAll方法:

        private void doSignalAll(Node first) {
            lastWaiter = firstWaiter  = null;
            do {
                Node next = first.nextWaiter;
                first.nextWaiter = null;
                transferForSignal(first);
                first = next;
            } while (first != null);
        }

这个方法就相当于把Condition队列中的所有Node全部取出插入到等待队列中去。

总结:

在了解了await(),signal()和signalAll方法的实现以后,我们再来通过一副gif动画来看一看这一个整体的过程:
animation

Java并发编程J.U.C之锁的获取与释放

上一篇文章中,我们对J.U.C的一些大概的情况做了了解,在这一篇文章我们将来以ReentrantLock为例,来分析一下锁的获取和释放的过程,让大家能够对锁的获取和释放的整体过程有一个了解。

一、锁的获取

先看下ReentrantLock的lock()方法,整个方法只有一行,调用acquire方法,看看acquire方法的实现:

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

这段代码的实现也是比较简洁,先尝试一次tryAcquire操作,如果失败,则把当前线程加入到同步队列中去,这个时候可能会反复的阻塞与唤醒这个线程,直到后续的tryAcquire(看acquireQueued的实现)操作成功。

再看看tryAcquire的实现:

        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (isFirst(current) &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

这段代码是尝试获取锁的过程,它先判断当前的AQS的state值,如果为0,则表示该锁没有被持有过,如果这个时候同步队列是空的或者当前线程就是在同步队列的头部,那么修改state的值,并且设置排他锁的持有线程为当前线程

如果大于0,则判断当前线程是否是排他锁的持有线程,如果是,那么把state值加1(注意state是int类型的,所以state的最大值是就是int的最大值)

如果第一次tryAcquire()操作失败,那么就把当前线程加入到等待队列中去,看addWaiter()方法:

    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

这段代码中先尝试了一下了下enq()方法中等待队列不为空的情况,如果失败,再调用enq()方法将当前线程加入等待队列,enq()的过程我们已经在上一篇文章中讲过了,不再赘述。

最后在当前线程被加入到等待队列中去以后,再调用acquireQueued去获取锁,看看acquireQueued的代码:

    final boolean acquireQueued(final Node node, int arg) {
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } catch (RuntimeException ex) {
            cancelAcquire(node);
            throw ex;
        }
    }

这段代码中拿到当前线程在同步队列中的前面一个节点,如果这个节点是是头部,那么马上进行一次tryAcquire操作,如果操作成功,那么把当前线程弹出队列,整个操作就此结束。如果这个节点不是头部或者说tryAcquire操作失败的话,那么就判断是不是要将当前线程给阻塞掉(shouldParkAfterFailedAcquire)方法:判断当前线程是否应该被阻塞掉,实际上判断的是当前线程的前一个节点的状态,如果前一个节点的状态小于0(condition或者signal),那么返回true,阻塞当前线程;如果前一个节点的状态大于0(cancelled),则向前遍历,直到找到一个节点状态不大于0的节点,并且将中间的cancelled状态的节点全部踢出队列;如果前一个节点的状态等于0,那么将其状态置为-1(signal),并且返回false,等待下一次循环的时候再阻塞。

整个锁的获取过程就是这样,我们再来总结一下整个过程:acquire()方法会先调用一次tryAcquire方法获取一次锁,如果失败,则把当前线程加入到等待队列中去,然后再调用acquireQueued获取锁,acquireQueued在当前节点不在头部的时候会把当前线程的前一个结点的状态置为SIGNAL,然后阻塞当前线程。当当前线程到了队列的头部的时候,那么获取锁的操作就会成功返回。

二、锁的释放

首先,我们知道在acquireQueued方法中,如果一个线程成功获取到了锁,那么它就应该是整个等待队列的head节点,然后,我们再来看一看unlock()方法,和lock()方法一样,unlock()方法也是只有一行代码,直接调用release()方法,我们看看release()方法的实现:

    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

这个过程首先调用tryRelease方法,如果锁已经完全释放,那么就唤醒下一个节点,先来看看tryRelease方法:

        protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

这段代码首先获取当前AQS的state状态并且将其值减一,如果结果等于0(锁已经被完全释放),那么将排他锁的持有线程置为null。将AQS的state状态置为减一后的结果。

然后再看看唤醒继任节点的代码:

    private void unparkSuccessor(Node node) {
        compareAndSetWaitStatus(node, Node.SIGNAL, 0);
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }

这段代码先清除当前节点的waitStatus为0,然后判断下一个节点是不是null或者cancelled的状态,如果是,则从队列的尾部往前开始找,找到一个非cancelled状态的节点,最后唤醒这个节点。

最后,总结一下释放操作的整个过程:其实整个释放过程就做了两件事情,一个是将state值减1,然后就是判断锁是否被完全释放,如果被完全释放,则唤醒继任节点。

三、整体过程描述

看了上面的锁的获取与释放操作以后,整体过程还是比较清晰的,在文章的最后,我们把获取与释放操作串在一起在简单看一下:

  • 获取锁的时候将当前线程放入同步队列,并且将前一个节点的状态置为signal状态,然后阻塞
  • 当这个节点的前一个节点成功获取到锁,前一个节点就成了整个同步队列的head。
  • 当前一个节点释放锁的时候,它就唤醒当前线程的这个节点,然后当前线程的节点就可以成功获取到锁了
  • 这个时候它就到整个队列的头部了,然后release操作的时候又可以唤醒下一个。

Tomcat Wrapper组件

一些基本概念
1、ServletContext:
作用:表示一个web应用的上下文;可以想象成一个Web应用程序的共享数据区域,该区域保存该Web应用程序的共享数据;
生命周期:每个Web应用程序都对应一个ServletContext,保存在Context中,在Context初始化时创建,Context撤销时销毁;
2、servlet-mapping:
作用:按url将请求匹配到servlet;
匹配过程:1) url按最长context path匹配当前Host下的Context;
2) 余下的将用于匹配该Context下的Servlet;
匹配规则,顺序如下:
1) 精确匹配:如/user/login;必须以/开头,不能以/*结尾;
2) 通配符匹配:如/customers/*,以最长串优先依次匹配;
3) 扩展名匹配:如/user/register.jsp;任何以*开头,以jsp结尾的mapping都会匹配;
4) 默认匹配:上述3种匹配失败后,将匹配到该mapping上;

3、Filter:
作用:Filter使用户可以改变一个request和修改一个response,它不是一个servlet,也不能产生response,它能够在一个request到达servlet之前预处理request,也可以在response离开servlet时处理response。
类图:如下
filter
其中:
1) FilterDef用于保存从web.xml解析出来的filter定义,包含filterName, filterClass, init-param等;
2) FilterMap用于保存从web.xml解析出来的filter-mapping配置;
3) 当初始化完所有的FilterDef以及FilterMap后,容器会初始化ApplicationFilterConfig,用于Filter内部访问Tomcat容器,如Filter的init-param, ServletContext等;
4) 解析出来的FilterDef、FilterMap以及ApplicationFilterConfig均保存在StandardContext中;
4、Listener:
作用:通过在web.xml中配置<listener>元素,可以在适当的时候收到Tomcat容器的事件通知,从而可以做出相应的响应;
类型:
1) 事件类型:当某事件发生时触发;
a) ServletContextAttributeListener:当ServletContext的属性发生变化(新增、修改、删除)时触发;
b) ServletRequestAttributeListener:当request的属性发生变化(新增、修改、删除)时响应;
c) ServletRequestListener:当请求在经Filter链处理前后时响应;
d) HttpSessionAttributeListener:当session中的属性发生变化(新增、修改、删除)时响应;
2) 生命周期类型:在生命周期中的某个点触发;
a) ServletContextListener:在ServletContext初始化完成和销毁时触发;
b) HttpSessionListener:在session创建和销毁时触发;

重要的数据结构
1、Mapper:
保存Tomcat容器中所有Host, Context, Wrapper及servlet-mapping的映射关系;
2、MappingData:
当前请求经过Mapper后,即决定将该请求交给哪个Host, 哪个Context, 哪个Wrapper来处理;这些数据组成MappingData;

创建ServletContext
1、ServletContext类图
servletcontext
这里采用了门面模式,ApplicationContext仅供tomcat内部使用,在Servlet中取得的servletContext实际上是ApplicationContextFacade的实例,防止外部修改tomcat容器中重要的数据结构;
2、实例化ServletContext
实例化ServletContext是通过StandardContext.getServletContext()方法来完成的:

public ServletContext getServletContext() {
    if (context == null) {
        context = new ApplicationContext(getBasePath(), this);
        if (altDDName != null)
            context.setAttribute(Globals.ALT_DD_ATTR,altDDName);
    }
    return (context.getFacade());
}

解析部署描述符web.xml
1、初始化Wrapper
当StandardContext初始化时,会解析web.xml文件(参考WebRuleSet);当解析到web-app/servlet标签时会调用StandardContext.createWrapper()方法,从而构造Wrapper组件,并将其作为子节点添加到当前Context下;
初始化Wrapper后,会设置与该servlet相关的配置,如servlet-name, servlet-class, init-param, jsp-file, load-on-startup等;这些配置值都是刚才构建出来的Wrapper组件的属性;
2、初始化servlet-mapping
由于servlet-mapping是针对Context的,处理servlet-mapping的工作由Context来完成,主要工作如下:
1) 根据servert-name找到该Context的子节点Wrapper,然后将该mapping添加到Wrapper中;
2) 将该Wrapper添加到当前Context的Mapper中,供ServletContext使用;
3、初始化filter及filter-mapping
1) 解析filter:调用StandardContext.addFilterDef(FilterDef filterDef),如下:

    public void addFilterDef(FilterDef filterDef) {
        synchronized (filterDefs) {
            filterDefs.put(filterDef.getFilterName(), filterDef);
        }
        fireContainerEvent("addFilterDef", filterDef);
    }

即:将filterDef以filterName为key保存在Map中;
2) 解析filter-mapping:调用StandardContext.addFilterMap(FilterMap filterMap),如下:

    public void addFilterMap(FilterMap filterMap) {
        // 先会做一些校验
        synchronized (filterMaps) {
            FilterMap results[] =new FilterMap[filterMaps.length + 1];
            System.arraycopy(filterMaps, 0, results, 0, filterMaps.length);
            results[filterMaps.length] = filterMap;
            filterMaps = results;
        }
        fireContainerEvent("addFilterMap", filterMap);
    }

3) 初始化ApplicationFilterConfig:当StandardContext启动时,会通过filterStart()方法来初始化ApplicationFilterConfig:将1)中保存的每个filterDef和当前StandardContext包装成一个ApplicationFilterConfig,供后面的创建filter链时使用;
4、初始化listener
当解析到web.xml中的<listener>元素时,会调用Standard.addApplicationListener(String listener)将listener的class信息保存起来,然后在StandardContext启动时,通过listenerStart()方法来初始化listener:实例化先前保存起来的listener,并按事件/生命周期分类保存其实例;
此时StandardContext初始化也快完成了,因此会触发ServletContextListener.contextInitialized()方法;

 

Servlet的loadOnStartup
在配置Servlet时,可以指定其loadOnStartup属性,该属性值决定了Servlet在容器启动后是否加载及加载顺序,默认为-1,表示不加载;
StandardContext在加载完所有Servlet配置后,会检查当前Context下的所有Wrapper的loadOnStartup属性值,当值大于0时,通过TreeMap按loadOnStartup从小到大排序后,分别调用每个Wrapper.load()方法来完成Servlet的初始化:
1) 根据servletClass是否是Tomcat内部servlet,决定是用webappClassloader还是用serverClassloader来装载servletClass;
2) 实例化servletClass;
3) 如果servlet是单线程(即一个servlet实例同时只能处理一个请求),则初始化一个servlet pool,用于存放空闲的servlet实例;后面在处理请求时分配servlet则会用到该servlet pool;

Mapper相关
1、先看看Mapper相关的类图
mapper
请不要把上图中的Host, Context, Wrapper和Tomcat中的Host组件、Context组件、Wrapper组件相混淆了,它们仅仅代表这三个组件的映射关系,真正所对应的组件实例引用存放在MapperElement抽象类中的object属性上;
2、初始化Mapper结构
我们再来回顾一下Tomcat容器的初始化过程:
1) 解析server.xml(由Catalina类来完成),同时调用StandardServer.start()方法来初始化Server组件;
2) Server组件初始化时,调用StandardService.start()方法来初始化Service组件;
3) 在StandardService.start()中,先完成所有内嵌组件的初始化(Engine, Host, Context, Wrapper等),然后调用Connect.start()方法来初始化Connector组件;
4) 由于在Connector初始化时,所有的内嵌组件都已初始化完毕,此时便可以完成Mapper的构造了;
初始化Mapper主要是由MapperListener来完成(在Connector.start()中调用MapperListener.init()方法):
1) 注册Engine:找到defaultHost,并设置Mapper的defaultHostName属性;
2) 注册所有的Host:针对每个Host组件,都构造一个Mapper$Host实例,name属性为该Host组件的name,object属性即该Host组件;另外,针对Host组件的别名,也会产生新的Mapper$Host实例,不过其object和Mapper$contextList的引用相同;
3) 注册所有的Context:针对每个Context组件,根据其hostName,将其加到对应Mapper$Host实例的Mapper$contextList中去;
4) 注册所有的Wrapper:和注册Context类似,将每个Wrapper组件根据其servlet-mapping保存到Mapper$Context的相应属性上;
3、MappingData的构造
当请求到达后,在交给Engine处理前,会构造MappingData(见CoyoteAdapter.postParseRequest()方法):
1) 根据请求的host属性,从Mapper中找到相应的Host组件及Mapper$Context数组;此时如果没有指定host属性的Host组件,则取defaultHostName所对应的Host组件;
2) 根据请求的uri,找到Context组件;
3) 根据请求的uri,按servlet-mapping规则,依次查找,直接找到对应的Wrapper组件;此时如果找不到,则依次查找welcomeFile所对应Wrapper组件;
4) 如果最后还是没有找到,则返回defaultWrapper组件;
5) 将匹配到的Host, Context, Wrapper保存在request中;

Wrapper组件对请求的处理
当MappingData构造完成后,CoyoteAdapter便将请求交给Engine、Host、Context、Wrapper组件进行处理;在Context组件中,StandardContextValve直接从request中取出Wrapper,然后交给它处理;下面看看Wrapper组件是如何处理的?
1、StandardWrapperValve
Wrapper组件对请求的处理,是通过StandardWrapperValve来完成的:
1) 从Wrapper中分配一个servlet实例;
2) 根据当前servlet和requestPath将匹配到的filter加到filter链中;
3) 调用filter chain处理请求和响应;当所有filter执行完,最后才执行servlet.service()方法;