ConcurrentLinkedDeque类详解

一、Queue接口定义

boolean add(E e);//入列 会抛出异常

boolean offer(E e);//入列

E remove();//出列 会抛出异常

E poll();//出列

E element();//读取 会抛出异常

E peek();//读取

Queue是一种具有FIFO特点的数据结构,元素只能在队首进行“入列”操作,在队尾进行“出列”操作。Queue的接口非常简单,一共只有三种类型的操作:入列、出列、读取。

每种操作类型,都给出了两种方法,区别就是其中一种操作在队列的状态不满足某些要求时,会抛出异常;另一种,则直接返回特殊值(如null)。

再来看下JDK中QueueDeque这两种数据结构的接口定义,看看Deque和Queue相比有哪些增强:

二、Deque接口定义

Deque(double-ended queue)是一种双端队列,也就是说可以在任意一端进行“入列”,也可以在任意一端进行“出列”。

Queue接口的所有方法Deque都具备,只不过队首/队尾都可以进行“出列”和“入列”操作:

void addFirst(E e);//队首入列 会抛出异常

void addLast(E e);//队尾入列 会抛出异常

boolean offerFirst(E e);//队首入列

boolean offerLast(E e);//队尾入列

E removeFirst();//队首出列 会抛出异常

E removeLast();//队尾出列 会抛出异常

E pollFirst();//队首出列

E pollLast();//队尾出列

E getFirst();//队首读取 会抛出异常

E getLast();//队尾读取 会抛出异常

E peekFirst();//队首读取

E peekLast();//队尾读取

除此之外,Deque还可以当作“栈”来使用,我们知道“栈”是一种具有“LIFO”特点的数据结构,Deque提供了pushpoppeek这三个栈方法,一般实现这三个方法时,可以利用已有方法,即有如下映射关系:

Comparison of Stack and Deque methods
Stack Method Equivalent Deque Method
push(e) addFirst(e)
pop() removeFirst()
peek() peekFirst()

官网连接:https://docs.oracle.com/javase/8/docs/api/

三、ConcurrentLinkedDeque简介

ConcurrentLinkedDeque是JDK1.7时,J.U.C包引入的一个集合工具类。在JDK1.7之前,除了Stack类外,并没有其它适合并发环境的“栈”数据结构。ConcurrentLinkedDeque作为双端队列,可以当作“栈”来使用,并且高效地支持并发环境。

ConcurrentLinkedDequeConcurrentLinkedQueue一样,采用了无锁算法,底层基于自旋+CAS的方式实现。

Class ConcurrentLinkedDeque<E>

 

Class ConcurrentLinkedQueue<E>

四、ConcurrentLinkedDeque原理

1.队列结构:

我们先来看下ConcurrentLinkedDeque的内部结构:

public class ConcurrentLinkedDeque<E> extends AbstractCollection<E>
    implements Deque<E>, java.io.Serializable {

    /**
     * 头指针
     */
    private transient volatile Node<E> head;

    /**
     * 尾指针
     */
    private transient volatile Node<E> tail;

    private static final Node<Object> PREV_TERMINATOR, NEXT_TERMINATOR;
    
    // Unsafe mechanics
    private static final sun.misc.Unsafe UNSAFE;
    private static final long headOffset;
    private static final long tailOffset;

    static {
        PREV_TERMINATOR = new Node<Object>();
        PREV_TERMINATOR.next = PREV_TERMINATOR;
        NEXT_TERMINATOR = new Node<Object>();
        NEXT_TERMINATOR.prev = NEXT_TERMINATOR;
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class<?> k = ConcurrentLinkedDeque.class;
            headOffset = UNSAFE.objectFieldOffset(k.getDeclaredField("head"));
            tailOffset = UNSAFE.objectFieldOffset(k.getDeclaredField("tail"));
        } catch (Exception e) {
            throw new Error(e);
        }
    }
    
    /**
     * 双链表结点定义
     */
    static final class Node<E> {
        volatile Node<E> prev;  // 前驱指针
        volatile E item;        // 结点值
        volatile Node<E> next;  // 后驱指针

        Node() {
        }

        Node(E item) {
            UNSAFE.putObject(this, itemOffset, item);
        }

        boolean casItem(E cmp, E val) {
            return UNSAFE.compareAndSwapObject(this, itemOffset, cmp, val);
        }

        void lazySetNext(Node<E> val) {
            UNSAFE.putOrderedObject(this, nextOffset, val);
        }

        boolean casNext(Node<E> cmp, Node<E> val) {
            return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, val);
        }

        void lazySetPrev(Node<E> val) {
            UNSAFE.putOrderedObject(this, prevOffset, val);
        }

        boolean casPrev(Node<E> cmp, Node<E> val) {
            return UNSAFE.compareAndSwapObject(this, prevOffset, cmp, val);
        }

        // Unsafe mechanics

        private static final sun.misc.Unsafe UNSAFE;
        private static final long prevOffset;
        private static final long itemOffset;
        private static final long nextOffset;

        static {
            try {
                UNSAFE = sun.misc.Unsafe.getUnsafe();
                Class<?> k = Node.class;
                prevOffset = UNSAFE.objectFieldOffset(k.getDeclaredField("prev"));
                itemOffset = UNSAFE.objectFieldOffset(k.getDeclaredField("item"));
                nextOffset = UNSAFE.objectFieldOffset(k.getDeclaredField("next"));
            } catch (Exception e) {
                throw new Error(e);
            }
        }
    }
    
    // ...
}

可以看到,ConcurrentLinkedDeque的内部和ConcurrentLinkedQueue类似,不过是一个双链表结构,每入队一个元素就是插入一个Node类型的结点。字段head指向队列头,tail指向队列尾,通过Unsafe来CAS操作字段值以及Node对象的字段值。

QQ截图20181130105240

需要特别注意的是ConcurrentLinkedDeque包含两个特殊字段:PREV_TERMINATOR、NEXT_TERMINATOR。
这两个字段初始时都指向一个值为null的空结点,这两个字段在结点删除时使用,后面会详细介绍:

QQ截图20181130105328

2.构造器定义

ConcurrentLinkedDeque包含两种构造器:

/**
 * 空构造器.
 */
public ConcurrentLinkedDeque() {
    head = tail = new Node<E>(null);

}
/**
 * 从已有集合,构造队列
 */
public ConcurrentLinkedDeque(Collection<? extends E> c) {
    Node<E> h = null, t = null;
    for (E e : c) {
        checkNotNull(e);
        Node<E> newNode = new Node<E>(e);
        if (h == null)
            h = t = newNode;
        else {  // 在队尾插入元素
            t.lazySetNext(newNode);
            newNode.lazySetPrev(t);
            t = newNode;
        }
    }
    initHeadTail(h, t);
}

我们重点看下空构造器,通过空构造器建立的ConcurrentLinkedDeque对象,其head和tail指针并非指向null,而是指向一个item值为null的Node结点——哨兵结点,如下图:

QQ截图20181130105328

3.入队操作

双端队列与普通队列的入队区别是:双端队列既可以在“队尾”插入元素,也可以在“队首”插入元素。ConcurrentLinkedDeque的入队方法有很多:addFirst(e)addLast(e)offerFirst(e)offerLast(e)

public void addFirst(E e) {
    linkFirst(e);
}

public void addLast(E e) {
    linkLast(e);
}

public boolean offerFirst(E e) {
    linkFirst(e);
    return true;
}

public boolean offerLast(E e) {
    linkLast(e);
    return true;
}

可以看到,队首“入队”其实就是调用了linkFirst(e)方法,而队尾“入队”是调用了 linkLast(e)方法。我们先来看下队首“入队”——linkFirst(e):

/**
 * 在队首插入一个元素.
 */
private void linkFirst(E e) {
    checkNotNull(e);
    final Node<E> newNode = new Node<E>(e); // 创建待插入的结点

    restartFromHead:
    for (; ; )
        for (Node<E> h = head, p = h, q; ; ) {
            if ((q = p.prev) != null && (q = (p = q).prev) != null)
                // Check for head updates every other hop.
                // If p == q, we are sure to follow head instead.
                p = (h != (h = head)) ? h : q;
            else if (p.next == p) // PREV_TERMINATOR
                continue restartFromHead;
            else {
                // p is first node
                newNode.lazySetNext(p); // CAS piggyback
                if (p.casPrev(null, newNode)) {
                    // Successful CAS is the linearization point
                    // for e to become an element of this deque,
                    // and for newNode to become "live".
                    if (p != h) // hop two nodes at a time
                        casHead(h, newNode);  // Failure is OK.
                    return;
                }
                // Lost CAS race to another thread; re-read prev
            }
        }
}

为了便于理解,我们以示例来看:假设有两个线程ThreadA和ThreadB同时进行入队操作。

①ThreadA先单独入队一个元素9

此时,ThreadA会执行CASE3分支:

else {                              // CASE3: p是队首结点
    newNode.lazySetNext(p);         // “新结点”的next指向队首结点
    if (p.casPrev(null, newNode)) { // 队首结点的prev指针指向“新结点”
        if (p != h) // hop two nodes at a time
            casHead(h, newNode);  // Failure is OK.
        return;
    }
    // 执行到此处说明CAS操作失败,有其它线程也在队首插入元素
}

队列的结构如下:
QQ截图20181130105240


②ThreadA入队一个元素2,同时ThreadB入队一个元素10

此时,依然执行CASE3分支,我们假设ThreadA操作成功,ThreadB操作失败:

else {                              // CASE3: p是队首结点
    newNode.lazySetNext(p);         // “新结点”的next指向队首结点
    if (p.casPrev(null, newNode)) { // 队首结点的prev指针指向“新结点”
        if (p != h) // hop two nodes at a time
            casHead(h, newNode);  // Failure is OK.
        return;
    }
    // 执行到此处说明CAS操作失败,有其它线程也在队首插入元素
}

ThreadA的CAS操作成功后,会进入以下判断:

if (p != h) // hop two nodes at a time
    casHead(h, newNode);  // Failure is OK.

上述判断的作用就是重置head头指针,可以看到,ConcurrentLinkedDeque其实是以每次跳2个结点的方式移动指针,这主要考虑到并发环境以这种hop跳的方式可以提升效率。

此时队列的机构如下:
QQ截图20181130105240

注意,此时ThreadB的p.casPrev(null, newNode)操作失败了,所以会进入下一次自旋,在下一次自旋中继续进入CASE3。如果ThreadA的casHead操作没有完成,ThreadB就进入了下一次自旋,则会进入分支1,重置指针p指向队首。最终队列结构如下:

QQ截图20181130105328

在队尾插入元素和队首类似,不再赘述,读者可以自己阅读源码。

4.出队操作

ConcurrentLinkedDeque的出队一样分为队首、队尾两种情况:removeFirst()pollFirst()removeLast()pollLast()

public E removeFirst() {
    return screenNullResult(pollFirst());
}

public E removeLast() {
    return screenNullResult(pollLast());
}

public E pollFirst() {
    for (Node<E> p = first(); p != null; p = succ(p)) {
        E item = p.item;
        if (item != null && p.casItem(item, null)) {
            unlink(p);
            return item;
        }
    }
    return null;
}

public E pollLast() {
    for (Node<E> p = last(); p != null; p = pred(p)) {
        E item = p.item;
        if (item != null && p.casItem(item, null)) {
            unlink(p);
            return item;
        }
    }
    return null;
}

可以看到,两个remove方法其实内部都调用了对应的poll方法,我们重点看下队尾的“出队”——pollLast方法:

public E pollLast() {
    for (Node<E> p = last(); p != null; p = pred(p)) {
        E item = p.item;
        if (item != null && p.casItem(item, null)) {
            unlink(p);
            return item;
        }
    }
    return null;
}

last方法用于寻找队尾结点,即满足p.next == null && p.prev != p的结点:

Node<E> last() {
    restartFromTail:
    for (; ; )
        for (Node<E> t = tail, p = t, q; ; ) {
            if ((q = p.next) != null &&
                (q = (p = q).next) != null)
                // Check for tail updates every other hop.
                // If p == q, we are sure to follow tail instead.
                p = (t != (t = tail)) ? t : q;
            else if (p == t
                // It is possible that p is NEXT_TERMINATOR,
                // but if so, the CAS is guaranteed to fail.
                || casTail(t, p))
                return p;
            else
                continue restartFromTail;
        }
}

pred方法用于寻找当前结点的前驱结点(如果前驱是自身,则返回队尾结点):

final Node<E> pred(Node<E> p) {
    Node<E> q = p.prev;
    return (p == q) ? last() : q;
}

unlink方法断开结点的链接:

/**
 * Unlinks non-null node x.
 */
void unlink(Node<E> x) {
    // assert x != null;
    // assert x.item == null;
    // assert x != PREV_TERMINATOR;
    // assert x != NEXT_TERMINATOR;

    final Node<E> prev = x.prev;
    final Node<E> next = x.next;
    if (prev == null) {
        unlinkFirst(x, next);
    } else if (next == null) {
        unlinkLast(x, prev);
    } else {
        Node<E> activePred, activeSucc;
        boolean isFirst, isLast;
        int hops = 1;

        // Find active predecessor
        for (Node<E> p = prev; ; ++hops) {
            if (p.item != null) {
                activePred = p;
                isFirst = false;
                break;
            }
            Node<E> q = p.prev;
            if (q == null) {
                if (p.next == p)
                    return;
                activePred = p;
                isFirst = true;
                break;
            } else if (p == q)
                return;
            else
                p = q;
        }

        // Find active successor
        for (Node<E> p = next; ; ++hops) {
            if (p.item != null) {
                activeSucc = p;
                isLast = false;
                break;
            }
            Node<E> q = p.next;
            if (q == null) {
                if (p.prev == p)
                    return;
                activeSucc = p;
                isLast = true;
                break;
            } else if (p == q)
                return;
            else
                p = q;
        }

        // TODO: better HOP heuristics
        if (hops < HOPS
            // always squeeze out interior deleted nodes
            && (isFirst | isLast))
            return;

        // Squeeze out deleted nodes between activePred and
        // activeSucc, including x.
        skipDeletedSuccessors(activePred);
        skipDeletedPredecessors(activeSucc);

        // Try to gc-unlink, if possible
        if ((isFirst | isLast) &&

            // Recheck expected state of predecessor and successor
            (activePred.next == activeSucc) &&
            (activeSucc.prev == activePred) &&
            (isFirst ? activePred.prev == null : activePred.item != null) &&
            (isLast ? activeSucc.next == null : activeSucc.item != null)) {

            updateHead(); // Ensure x is not reachable from head
            updateTail(); // Ensure x is not reachable from tail

            // Finally, actually gc-unlink
            x.lazySetPrev(isFirst ? prevTerminator() : x);
            x.lazySetNext(isLast ? nextTerminator() : x);
        }
    }
}

ConcurrentLinkedDeque相比ConcurrentLinkedQueue,功能更丰富,但是由于底层结构是双链表,且完全采用CAS+自旋的无锁算法保证线程安全性,所以需要考虑各种并发情况,源码比ConcurrentLinkedQueue更加难懂,留待有精力作进一步分析。

五、总结

ConcurrentLinkedDeque使用了自旋+CAS的非阻塞算法来保证线程并发访问时的数据一致性。由于队列本身是一种双链表结构,所以虽然算法看起来很简单,但其实需要考虑各种并发的情况,实现复杂度较高,并且ConcurrentLinkedDeque不具备实时的数据一致性,实际运用中,如果需要一种线程安全的栈结构,可以使用ConcurrentLinkedDeque。

另外,关于ConcurrentLinkedDeque还有以下需要注意的几点:

  1. ConcurrentLinkedDeque的迭代器是弱一致性的,这在并发容器中是比较普遍的现象,主要是指在一个线程在遍历队列结点而另一个线程尝试对某个队列结点进行修改的话不会抛出ConcurrentModificationException,这也就造成在遍历某个尚未被修改的结点时,在next方法返回时可以看到该结点的修改,但在遍历后再对该结点修改时就看不到这种变化。
  2. size方法需要遍历链表,所以在并发情况下,其结果不一定是准确的,只能供参考。

Nginx 配置文件 nginx.conf 详解

#定义Nginx运行的用户和用户组

user www www;

 

#nginx进程数,建议设置为等于CPU总核心数。

worker_processes 8;

 

#全局错误日志定义类型,[ debug | info | notice | warn | error | crit ]

error_log /var/log/nginx/error.log info;

 

#进程文件

pid /var/run/nginx.pid;

 

#一个nginx进程打开的最多文件描述符数目,理论值应该是最多打开文件数(系统的值ulimit -n)与nginx进程数相除,但是nginx分配请求并不均匀,所以建议与ulimit -n的值保持一致。

worker_rlimit_nofile 65535;

 

#工作模式与连接数上限

events

{

#参考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型。

use epoll;

#单个进程最大连接数(最大连接数=连接数*进程数)

worker_connections 65535;

}

 

#设定http服务器

http

{

include mime.types; #文件扩展名与文件类型映射表

default_type application/octetstream; #默认文件类型

#charset utf-8; #默认编码

server_names_hash_bucket_size 128; #服务器名字的hash表大小

client_header_buffer_size 32k; #上传文件大小限制

large_client_header_buffers 4 64k; #设定请求缓

client_max_body_size 8m; #设定请求缓

sendfile on; #开启高效文件传输模式,sendfile指令指定nginx是否调用sendfile函数来输出文件,对于普通应用设为 on,如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络I/O处理速度,降低系统的负载。注意:如果图片显示不正常把这个改成off。

autoindex on; #开启目录列表访问,合适下载服务器,默认关闭。

tcp_nopush on; #防止网络阻塞

tcp_nodelay on; #防止网络阻塞

keepalive_timeout 120; #长连接超时时间,单位是秒

 

#FastCGI相关参数是为了改善网站的性能:减少资源占用,提高访问速度。下面参数看字面意思都能理解。

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

fastcgi_buffer_size 64k;

fastcgi_buffers 4 64k;

fastcgi_busy_buffers_size 128k;

fastcgi_temp_file_write_size 128k;

 

#gzip模块设置

gzip on; #开启gzip压缩输出

gzip_min_length 1k; #最小压缩文件大小

gzip_buffers 4 16k; #压缩缓冲区

gzip_http_version 1.0; #压缩版本(默认1.1,前端如果是squid2.5请使用1.0)

gzip_comp_level 2; #压缩等级

gzip_types text/plain application/xjavascript text/css application/xml;

#压缩类型,默认就已经包含text/html,所以下面就不用再写了,写上去也不会有问题,但是会有一个warn。

gzip_vary on;

#limit_zone crawler $binary_remote_addr 10m; #开启限制IP连接数的时候需要使用

 

upstream blog.ha97.com {

#upstream的负载均衡,weight是权重,可以根据机器配置定义权重。weigth参数表示权值,权值越高被分配到的几率越大。

server 192.168.80.121:80 weight=3;

server 192.168.80.122:80 weight=2;

server 192.168.80.123:80 weight=3;

}

 

#虚拟主机的配置

server

{

    #监听端口

    listen 80;

    #域名可以有多个,用空格隔开

    server_name www.ha97.com ha97.com;

    index index.html index.htm index.php;

    root /data/www/ha97;

    location ~ .*\.(php|php5)?$

    {

    fastcgi_pass 127.0.0.1:9000;

    fastcgi_index index.php;

    include fastcgi.conf;

    }

    #图片缓存时间设置

    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$

    {

    expires 10d;

    }

    #JS和CSS缓存时间设置

    location ~ .*\.(js|css)?$

    {

    expires 1h;

    }

    #日志格式设定

    log_format access ‘$remote_addr – $remote_user [$time_local] “$request” ‘

    ‘$status $body_bytes_sent “$http_referer” ‘

    ‘”$http_user_agent” $http_x_forwarded_for’;

    #定义本虚拟主机的访问日志

    access_log /var/log/nginx/ha97access.log access;

 

    #对 “/” 启用反向代理

    location / {

    proxy_pass http://127.0.0.1:88;

    proxy_redirect off;

    proxy_set_header XRealIP $remote_addr;

    #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP

    proxy_set_header XForwardedFor $proxy_add_x_forwarded_for;

    #以下是一些反向代理的配置,可选。

    proxy_set_header Host $host;

    client_max_body_size 10m; #允许客户端请求的最大单文件字节数

    client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数,

    proxy_connect_timeout 90; #nginx跟后端服务器连接超时时间(代理连接超时)

    proxy_send_timeout 90; #后端服务器数据回传时间(代理发送超时)

    proxy_read_timeout 90; #连接成功后,后端服务器响应时间(代理接收超时)

    proxy_buffer_size 4k; #设置代理服务器(nginx)保存用户头信息的缓冲区大小

    proxy_buffers 4 32k; #proxy_buffers缓冲区,网页平均在32k以下的设置

    proxy_busy_buffers_size 64k; #高负荷下缓冲大小(proxy_buffers*2)

    proxy_temp_file_write_size 64k;

    #设定缓存文件夹大小,大于这个值,将从upstream服务器传

    }

 

    #设定查看Nginx状态的地址

    location /NginxStatus {

    stub_status on;

    access_log on;

    auth_basic “NginxStatus”;

    auth_basic_user_file conf/htpasswd;

    #htpasswd文件的内容可以用apache提供的htpasswd工具来产生。

    }

 

    #本地动静分离反向代理配置

    #所有jsp的页面均交由tomcat或resin处理

    location ~ .(jsp|jspx|do)?$ {

    proxy_set_header Host $host;

    proxy_set_header XRealIP $remote_addr;

    proxy_set_header XForwardedFor $proxy_add_x_forwarded_for;

    proxy_pass http://127.0.0.1:8080;

    }

    #所有静态文件由nginx直接读取不经过tomcat或resin

    location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|pdf|xls|mp3|wma)$

    { expires 15d; }

    location ~ .*.(js|css)?$

    { expires 1h; }

}

}

开源的许可证GPL、LGPL、BSD、Apache 2.0的通俗解释

软件开发者要开源软件,不单单是开放源代码就可以了,选择一种许可证很重要,一个许可证之于软件就相当于价值观之于普通人,代表了这个软件的基本品性。一个错误的许可证选择可能会直接导致整个项目的失败。

各种开源的许可证主要的限制还是在redistribution(发布),所以个人/商业公司开发的软件包含了GPL的代码,只要你不发布,是可以任意使用的。

下面是几个开源许可证的区别:

GPL
GPL软件的使用者有权力得到软件的代码,只要使用了GPL,在发布(redistribution)时,整个项目也必须是GPL的,即主程序和静态链接的库(linux的.a和Windows的.lib)必须是GPL的,动态链接库(Linux的.so,Windows的.dll)必须是GPL兼容的。所谓GPL兼容,也就是GPL软件中可以使用的库,这些许可证必须比GPL弱(如LGPL,BSD),而不能是某个商业许可证。正因如此,GPL是带有很强的传染性,只要你的软件使用了GPL的代码,那么就请以GPL开放源代码吧,并且你的项目中也不能有任何和GPL不兼容的库。

LGPL
GPL 带有很强的传染性,那么如果一个库使用GPL发布,那么使用这个库的所有软件也必须使用GPL发布,这对不想开放源代码的商业软件来讲是致命的打击——你可以不使用其他的库,但最基本的libc是无论如何绕不开的,如果libc是以GPL发布,就相当于所有软件必须以GPL发布了。所以,LGPL(Lesser GPL)诞生了。

LGPL定义为,在以LGPL发布的库的基础上开发新的库的时候,新的库必须以LGPL发布,但是如果仅仅是动态链接,那么则不受任何限制。这样商业软件就可以随意的使用LGPL的库了。因此,LGPL也具有传染性,但限制在其基础上开发的库上,而并不限制使用它的程序本身——它的传染性远小于GPL。

BSD、Apache 2.0
相对GPL/LGPL的开放源代码,BSD,Apache 2.0就宽松许多——商业软件可以任意的使用BSD,Apache 2.0发布的软件代码,而不需要开放源代码,只需要提及代码的原出处就可以了。BSD和Apache 2.0提及的方式稍有不同,具体可以参考协议的详细内容。它们是GPL兼容的

 

看看下面选择开源许可证的案例:

andorid 使用宽松的Apache 2.0发布,因为Google作为一个商业公司,并不想失去商业软件的支持,它希望团结一切可以团结的力量加入的Android的开发中来,壮大自己的阵营,使用Apache 2.0就无可厚非了。而Google本身,并没有丧失对Android的控制权,不会担心另外一个公司拿走了Android的代码开发出一个闭源 Android的对手。因为,只要Android不断的出新版,社区不停的跟进,并且不停的修改API,其他基于Android开发的公司不得不把自己的Patch提回到主干上,否则,必然将耗费大量人力物力在维护自己的Patch上(钱这方面你斗得过Google?),得不偿失。而且,闭源之后,与整个社区为敌,作为一个定位软件平台的项目,会流失大量应用软件开发者,以小博大,任何一个商业公司都不会干这种胜算不高的蠢事。
再看以GPL发布的Linux为什么比以BSD发布的FreeBSD成功。其实正是因为GPL的传染性。当一个开发人员在Linux基础上开发一个新功能之后, 不得不以GPL开放源代码,贡献回Linux,这样Linux本身才能越来也越壮大而且留住了相当的开发人员,形成了一个 优秀软件->很多使用者和贡献者->贡献->更优秀的软件->更多的使用者和贡献者… 的良性循环。

 

Spring boot整合Redis做数据缓存

redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步,从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制,使得从数据库在任何地方同步树时,可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

redis的官网地址,非常好记,是redis.io。(特意查了一下,域名后缀io属于国家域名,是british Indian Ocean territory,即英属印度洋领地)目前,Vmware在资助着redis项目的开发和维护。

下面是官方的bench-mark数据:
测试完成了50个并发执行100000个请求。
设置和获取的值是一个256字节字符串。
Linux box是运行Linux 2.6,这是X3320 Xeon 2.5 ghz。
文本执行使用loopback接口(127.0.0.1)。
结果:读的速度是110000次/s,写的速度是81000次/s

redis提供五种数据类型:string,hash,list,set及zset(sorted set)。
string(字符串)
string是最简单的类型,你可以理解成与Memcached一模一样的类型,一个key对应一个value,其上支持的操作与Memcached的操作类似。但它的功能更丰富。
redis采用结构sdshdr和sds封装了字符串,字符串相关的操作实现在源文件sds.h/sds.c中。

list(双向链表)
list是一个链表结构,主要功能是push、pop、获取一个范围的所有值等等。操作中key理解为链表的名字。

dict(hash表)
set是集合,和我们数学中的集合概念相似,对集合的操作有添加删除元素,有对多个集合求交并差等操作。操作中key理解为集合的名字。

dict中table为dictEntry指针的数组,数组中每个成员为hash值相同元素的单向链表。set是在dict的基础上实现的,指定了key的比较函数为dictEncObjKeyCompare,若key相等则不再插入。

zset(排序set)
zset是set的一个升级版本,他在set的基础上增加了一个顺序属性,这一属性在添加修改元素的时候可以指定,每次指定后,zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表,一列存value,一列存顺序。操作中key理解为zset的名字。

zset利用dict维护key -> value的映射关系,用zsl(zskiplist)保存value的有序关系。zsl实际是叉数不稳定的多叉树,每条链上的元素从根节点到叶子节点保持升序排序。

tomcat配置SSL环境

生成安全证书:

1.java环境:因为SUN公司提供了制作证书的工具keytool。在JDK 1.4以后的版本中都包含了这一工具,它的位置为<JAVA_HOME>\bin\keytool.exe。

2.创建证书的命令:

Cmd代码
  1. keytool -genkeypair -alias “tomcat” -keyalg “RSA” -keystore “f:\tomcat.keystore”

参数的意思如下:

1505117109-4382-e190-3065-9e30-7633e955be16

这里密码我输的是tomcat,名字与姓氏为域名,其它的根据具体情况输入f38ff7b2-cfa7-3b70-b2ff-fa3588b462e7

 

以上命令将生产一对非对称密钥和自我签名的证书f:\tomcat.keystore.

将证书保存到你要存放的地方,我的保存在D:\Tools\Web\ssl\tomcat.keystore

注意:“名字与姓氏”应该是域名,输成了姓名,和真正运行的时候域名不符,会出问题

—————————————————————————————————————————

配置tomcat:

定位到tomcat的安装目录,找到conf下的server.xml文件

找到如下已经被注释的代码:

Xml代码
<!– <Connector port=”8443″ protocol=”org.apache.coyote.http11.Http11NioProtocol”
maxThreads=”150″ SSLEnabled=”true” scheme=”https” secure=”true” keystoreFile=”/root/shangdao.keystore” keystorePass=”111111″
clientAuth=”false” sslProtocol=”TLS” /> –>

去掉注释,修改为:

Xml代码
<Connector port=”8443″ protocol=”org.apache.coyote.http11.Http11NioProtocol”
maxThreads=”150″ SSLEnabled=”true” scheme=”https” secure=”true” keystoreFile=”/root/shangdao.keystore” keystorePass=”111111″
clientAuth=”false” sslProtocol=”TLS” />

这里,密码和证书的位置根据个人的具体环境而设置,属性参数如下所述:

属性 描述
clientAuth 如果设为true,表示Tomcat要求所有的SSL客户出示安全证书,对SSL客户进行身份验证
keystoreFile 指定keystore文件的存放位置,可以指定绝对路径,也可以指定相对于<CATALINA_HOME>(Tomcat安装目录)环境变量 的相对路径。如果此项没有设定,默认情况下,Tomcat将从当前操作系统用户的用户目录下读取名为“.keystore”的文件。
keystorePass 指定keystore的密码,如果此项没有设定,在默认情况下,Tomcat将使用“changeit”作为默认密码。
sslProtocol 指定套接字(Socket)使用的加密/解密协议,默认值为TLS,用户不应该修改这个默认值。
ciphers 指定套接字可用的用于加密的密码清单,多个密码间以逗号(,)分隔。如果此项没有设定,在默认情况下,套接字可以使用任意一个可用的密码。

访问支持ssl的web站点:

启动tomcat,在浏览器中输入:https://localhost:8443/。

QQ截图20170911161055

12320