summary

################
Redis 引发的问题：
	1、缓存雪崩
		如果缓存数据设置的过期时间是相同的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存同时失效，全部请求到数据库中。
		采用的是惰性删除+定期删除两种策略对过期键删除。
		缓存的时候给过期时间加上一个随机值。

		如何解决缓存雪崩：
		事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。
			主从架构+Sentinel: 
				https://www.cnblogs.com/kevingrace/p/9004460.html
			Redis Cluster:
		事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache) + 限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)。
			本地缓存(ehcache，一般 Redis作为一级缓存, ehcache作为二级缓存): https://blog.csdn.net/qq_34898847/article/details/89762974
				缓存数据有两级：内存和磁盘，因此无需担心容量问题
				缓存数据会在虚拟机重启的过程中写入磁盘。
				其核心是CacheManager，一切Ehcache的应用都是从CacheManager开始的。它是用来管理Cache（缓存）的，一个应用可以有多个CacheManager，而一个CacheManager下又可以有多个Cache。Cache内部保存的是一个个的Element，而一个Element中保存的是一个key和value的配对，相当于Map里面的一个Entry。
				Ehcache缓存过期策略：
					FIFO、LRU、LFU
			限流(hystrix):
		事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。
			如何快速恢复缓存数据：
				RDB和AOF持久化机制

	2、缓存穿透
		查询一个一定不存在的数据。由于缓存不命中，并且出于容错考虑，如果从数据库查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义。

		解决缓存穿透也有两种方案：
			a、由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter提前拦截，不合法就不让这个请求到数据库层！
				布隆过滤器实现（布隆过滤器是哈希表和位图的结合）：
					将所有可能存在的数据缓存放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。
					guava实现：com.google.guava-guava
			b、当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里边获取了。一般会将空对象设置一个较短的过期时间。
				但这样会把所有key都存下来，浪费大量内存空间，最后触发redis的缓存淘汰策略。
	3、缓存与数据库双写一致
		a、为什么是先删除缓存再更新数据库,而不是反过来？
		b、https://blog.51cto.com/14230003/2363051

################
Object类（7个native方法、3个wait()方法、个一个静态方法块、一个equals、一个finalize）：
	public class Object {

    private static native void registerNatives();
    static {
        registerNatives();
    }

    public final native Class<?> getClass();

    public native int hashCode();

    public boolean equals(Object obj) {
        return (this == obj);
    }

    /**
     * 浅拷贝 和 深拷贝
     */
    protected native Object clone() throws CloneNotSupportedException;

	/**
     * 该字符串由类名（对象是该类的一个实例）、标记符“@”和此对象哈希码的无符号十六进制表示组成。
     */
    public String toString() {
        return getClass().getName() + "@" + Integer.toHexString(hashCode());
    }

    /*唤醒在此对象监视器上等待的单个线程。*/
    public final native void notify();

    /*唤醒在此对象监视器上等待的所有线程。*/
    public final native void notifyAll();

    public final native void wait(long timeout) throws InterruptedException;

    public final void wait(long timeout, int nanos) throws InterruptedException {
        if (timeout < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException(
                                "nanosecond timeout value out of range");
        }

        if (nanos > 0) {
            timeout++;
        }

        wait(timeout);
    }

    public final void wait() throws InterruptedException {
        wait(0);
    }

    /**
     * 垃圾回收器准备释放内存的时候，会先调用finalize()。
     */
    protected void finalize() throws Throwable { }
}
		
################
map: merge、compute、computeIfAbsent、computeIfPresent、getOrDefault

################
一致性哈希（常用于负载均衡）
		具体实现：
			一致性哈希将整个哈希值空间组织成一个虚拟的圆环，可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，将数据key使用相同的函数H计算出哈希值h确定此数据在环上的位置，
		从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。
		容错性和可扩展性：
			容错性-如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
			可扩展性-如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
		虚拟节点：
			一致性哈希算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题。一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。
			具体做法可以在服务器ip或主机名的后面增加编号来实现。
		代码实现：
			import java.security.MessageDigest;
			import java.security.NoSuchAlgorithmException;
			import java.util.Collection;
			import java.util.SortedMap;
			import java.util.TreeMap;
			public class ConsistentHash<T> {
			    HashFunc hashFunc; // Hash计算对象，用于自定义hash算法
			    private final int numberOfReplicas; // 复制的节点个数
			    private final SortedMap<Long, T> circle = new TreeMap<>(); // 一致性Hash环

			    /**
			     * 构造，使用Java默认的Hash算法
			     * @param numberOfReplicas 复制的节点个数，增加每个节点的复制节点有利于负载均衡
			     * @param nodes            节点对象
			     */
			    public ConsistentHash(int numberOfReplicas, Collection<T> nodes) {
			        this.numberOfReplicas = numberOfReplicas;
			        this.hashFunc = new HashFunc() {
			            @Override
			            public Long hash(Object key) {
							// return fnv1HashingAlg(key.toString());
			                return md5HashingAlg(key.toString());
			            }
			        };
			        //初始化节点
			        for (T node : nodes) {
			            add(node);
			        }
			    }

			    /**
			     * 构造
			     * @param hashFunc         hash算法对象
			     * @param numberOfReplicas 复制的节点个数，增加每个节点的复制节点有利于负载均衡
			     * @param nodes            节点对象
			     */
			    public ConsistentHash(HashFunc hashFunc, int numberOfReplicas, Collection<T> nodes) {
			        this.numberOfReplicas = numberOfReplicas;
			        this.hashFunc = hashFunc;
			        //初始化节点
			        for (T node : nodes) {
			            add(node);
			        }
			    }

			    /**
			     * 增加节点<br>
			     * 每增加一个节点，就会在闭环上增加给定复制节点数<br>
			     * 例如复制节点数是2，则每调用此方法一次，增加两个虚拟节点，这两个节点指向同一Node
			     * 由于hash算法会调用node的toString方法，故按照toString去重
			     *
			     * @param node 节点对象
			     */
			    public void add(T node) {
			        for (int i = 0; i < numberOfReplicas; i++) {
			            circle.put(hashFunc.hash(node.toString() + i), node);
			        }
			    }

			    /**
			     * 移除节点的同时移除相应的虚拟节点
			     *
			     * @param node 节点对象
			     */
			    public void remove(T node) {
			        for (int i = 0; i < numberOfReplicas; i++) {
			            circle.remove(hashFunc.hash(node.toString() + i));
			        }
			    }

			    /**
			     * 获得一个最近的顺时针节点
			     *
			     * @param key 为给定键取Hash，取得顺时针方向上最近的一个虚拟节点对应的实际节点
			     * @return 节点对象
			     */
			    public T get(Object key) {
			        if (circle.isEmpty()) {
			            return null;
			        }
			        long hash = hashFunc.hash(key);
			        if (!circle.containsKey(hash)) {
			            SortedMap<Long, T> tailMap = circle.tailMap(hash); //返回此映射的部分视图，其键大于等于 hash
			            hash = tailMap.isEmpty() ? circle.firstKey() : tailMap.firstKey();
			        }
			        //正好命中
			        return circle.get(hash);
			    }

			    /**
			     * 使用MD5算法
			     * @param key
			     * @return
			     */
			    private static long md5HashingAlg(String key) {
			        MessageDigest md5 = null;
			        try {
			            md5 = MessageDigest.getInstance("MD5");
			            md5.reset();
			            md5.update(key.getBytes());
			            byte[] bKey = md5.digest();
			            long res = ((long) (bKey[3] & 0xFF) << 24) | ((long) (bKey[2] & 0xFF) << 16) | ((long) (bKey[1] & 0xFF) << 8)| (long) (bKey[0] & 0xFF);
			            return res;
			        } catch (NoSuchAlgorithmException e) {
			            e.printStackTrace();
			        }
			        return 0l;
			    }

			    /**
			     * 使用FNV1hash算法
			     * @param key
			     * @return
			     */
			    private static long fnv1HashingAlg(String key) {
			        final int p = 16777619;
			        int hash = (int) 2166136261L;
			        for (int i = 0; i < key.length(); i++)
			            hash = (hash ^ key.charAt(i)) * p;
			        hash += hash << 13;
			        hash ^= hash >> 7;
			        hash += hash << 3;
			        hash ^= hash >> 17;
			        hash += hash << 5;
			        return hash;
			    }

			    /**
			     * Hash算法对象，用于自定义hash算法
			     */
			    public interface HashFunc {
			        public Long hash(Object key);
			    }
			}

################
	排序：Collections.sort(consumeDetialList, Comparator.comparing(ConsumeDetialVO::getParse));

################
	重复数据合并：Map<String,List<ActMarketTagKeyDTO>> collect = tagKeyDTOS.stream().collect(Collectors.groupingBy(ActMarketTagKeyDTO::getActKey));

################
	InnoDB存储引擎中有页（Page）的概念，页是其磁盘管理的最小单位。InnoDB存储引擎中默认每个页的大小为16KB， 可通过参数innodb_page_size将页的大小设置为4K、8K、16K，在MySQL中可通过如下命令查看页的大小：
		show variables like 'innodb_page_size';

################
<? extends E>
<? super E>

################
zookeeper 都有哪些应用场景？
	分布式协调：
		这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zookeeper 
		就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上对某个节点的值注册个监听器，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。
	分布式锁
		
	元数据/配置信息管理
		zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？
	HA高可用性
		这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。

################
豆瓣书单：
	https://book.douban.com/subject/26792439/
	https://book.douban.com/subject/26912767/
	https://book.douban.com/subject/26941639/
	https://book.douban.com/subject/30335935/comments/
	https://book.douban.com/subject/30231515/comments/hot?p=3

################
https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247489683&idx=1&sn=8c1833a1c8a64c9230de772243dc472c&chksm=ebd627bfdca1aea9119ee327099531ce88108104ba78e0db27b8a9f4012fd249484a0f95bb4d&mpshare=1&scene=1&srcid=&sharer_sharetime=1568603345220&sharer_shareid=db798041d94b69fbcc5d91e179481c7a&key=2609303a4cd567e303c9e7373854b44df9fa8058e59174ff3f07b9c1a952964db45da9c296652b2ef135737e3da2f8458028dd9c67cdc927bdb4b67513f497ecab72c90a1f50c94b98f696ae2b784401&ascene=1&uin=MTE3MjAzNzc0MA%3D%3D&devicetype=Windows+7&version=62060833&lang=zh_CN&pass_ticket=IUGc8tYF7PU53RkiZq1d9qoUuuO%2F0R48igsSkF8y%2BWbYguRbUW7Q101rcvOXUYVo
SpringBoot 启动过程
SpringBoot 自动配置原理
ApplicationContextAware: 当一个类实现了这个接口（ApplicationContextAware）之后，这个类就可以方便获得ApplicationContext中的所有bean。换句话说，就是这个类可以直接获取spring配置文件中，所有有引用到的bean对象·

################
零内存拷贝（https://juejin.im/post/5c1b285de51d452f6028a98d）
	零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储的技术。
	零拷贝技术通过减少数据拷贝次数，简化协议处理的层次，在应用程序和网络之间提供更快的数据传输方法，从而可以有效地降低通信延迟，提高网络吞吐率。零拷贝技术是实现主机或者路由器等设备高速网络接口的主要技术之一。
	硬件和软件之间的数据传输可以通过使用 DMA 来进行，DMA  进行数据传输的过程中几乎不需要  CPU  参与。
	1).避免数据拷贝:
		a).避免操作系统内核缓冲区之间进行数据拷贝操作。
		b).避免操作系统内核和用户应用程序地址空间这两者之间进行数据拷贝操作。
		c).用户应用程序可以避开操作系统直接访问硬件存储。
		d).数据传输尽量让 DMA 来做。
	2).Linux 中的零拷贝技术主要有下面这几种：
		a).直接 I/O：
			对于这种数据传输方式来说，应用程序可以直接访问硬件存储，操作系统内核只是辅助数据传输：这类零拷贝技术针对的是操作系统内核并不需要对数据进行直接处理的情况，
			数据可以在应用程序地址空间的缓冲区和磁盘之间直接进行传输，完全不需要 Linux 操作系统内核提供的页缓存的支持。
		b).在数据传输的过程中，避免数据在操作系统内核地址空间的缓冲区和用户应用程序地址空间的缓冲区之间进行拷贝：
			有的时候，应用程序在数据进行传输的过程中不需要对数据进行访问，那么，将数据从 Linux 的页缓存拷贝到用户进程的缓冲区中就可以完全避免，传输的数据在页缓存中就可以得到处理。在某些特殊的情况下，
			这种零拷贝技术可以获得较好的性能。Linux 中提供类似的系统调用主要有 mmap()，sendfile() 以及 splice()。
		c).对数据在 Linux 的页缓存和用户进程的缓冲区之间的传输过程进行优化：
			该零拷贝技术侧重于灵活地处理数据在用户进程的缓冲区和操作系统的页缓存之间的拷贝操作。这种方法延续了传统的通信方式，但是更加灵活。在Linux中，该方法主要利用了写时复制技术。


###############################面试题###############################
1、生产环境中的redis是怎么部署的？
	面试官心里分析
		看看你了解不了解你们公司的redis生产集群的部署架构，如果你不了解，那么确实你就很失职了，你的redis是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？
		线上redis给几个G的内存？设置了哪些参数？压测后你们redis集群承载多少QPS？
	兄弟，这些你必须是门儿清的，否则你确实是没好好思考过
	面试题剖析
		redis cluster，10台机器，5台机器部署了redis主实例，另外5台机器部署了redis的从实例，每个主实例挂了一个从实例，5个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒5万，5台机器最多是25万读写请求/s。
	机器是什么配置？
		32G内存+8核CPU+1T磁盘，但是分配给redis进程的是10g内存，一般线上生产环境，redis的内存尽量不要超过10g，超过10g可能会有问题。5台机器对外提供读写，一共有50g内存。
		因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis从实例会自动变成主实例继续提供读写服务
	你往内存里写的是什么数据？每条数据的大小是多少？
		商品数据，每条数据是10kb。100条数据是1mb，10万条数据是1g。常驻内存的是200万条商品数据，占用内存是20g，仅仅不到总内存的50%。目前高峰期每秒就是3500左右的请求量。

2、redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？
	1).redis cluster 集群模式：
		a).Redis Cluster 是 Redis 的分布式解决方案。
		当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。
		分布式集群首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
		数据自动分片：
			aa).redis 的 key 是如何寻址的 ——> hash slot算法：
				redis cluster 有固定的 16384(2的14次方) 个 hash slot，对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。redis cluster 中每个 master 都会持有部分 slot
				任何一台机器宕机，另外两个节点，不影响的。因为 key 找的是 hash slot，不是机器。
			bb).分布式寻址都有哪些算法:
				hash 算法（大量缓存重建）
				一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
					具体实现：
							一致性哈希将整个哈希值空间组织成一个虚拟的圆环，可以选择服务器的ip或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，将数据key使用相同的函数H计算出哈希值h确定此数据在环上的位置，
						从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器。
						容错性和可扩展性：
							容错性-如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
							可扩展性-如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即顺着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。
						虚拟节点：
							一致性哈希算法在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题。一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。
							具体做法可以在服务器ip或主机名的后面增加编号来实现。
				redis cluster 的 hash slot 算法
		b).hash tags 功能:
			通过hash tag功能可以将多个不同key映射到同一个slot上，这样就能够提供 multi-key 操作
		c).通过 gossip 协议来进行节点之间通信:
			aa).所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。
			bb).gossip 协议好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续打到所有节点上去更新，降低了压力；不好在于，元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。
			cc).每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如 7001，那么用于节点间通信的就是 17001 端口。
			dd).每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其它几个节点接收到 ping 之后返回 pong。
			ee).交换的信息：
				信息包括故障信息，节点的增加和删除，hash slot 信息等等。
			ff).gossip 协议：
				gossip 协议包含多种消息，包含 ping,pong,meet,fail 等等：
					meet：某个节点发送 meet 给新加入的节点，让新节点加入集群中，然后新节点就会开始与其它节点进行通信。其实内部就是发送了一个 gossip meet 消息给新加入的节点，通知那个节点去加入我们的集群。
					ping：每个节点都会频繁给其它节点发送 ping，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping 交换元数据。
						每个节点每秒会执行 10 次 ping，每次会选择 5 个最久没有通信的其它节点。当然如果发现某个节点通信延时达到了 cluster_node_timeout / 2，那么立即发送 ping，避免数据交换延时过长，落后的时间太长了。
					pong：返回 ping 和 meeet，包含自己的状态和其它信息，也用于信息广播和更新。
					fail：某个节点判断另一个节点 fail 之后，就发送 fail 给其它节点，通知其它节点说，某个节点宕机啦。

	2).redis cluster 的高可用与主备切换原理：
		redis cluster 功能强大，直接集成了 replication 和 sentinel 的功能。
		判断节点宕机:
			如果一个节点认为另外一个节点宕机，那么就是 pfail，主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是 fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown。
			在 cluster-node-timeout 内，某个节点一直没有返回 pong，那么就被认为 pfail。
			如果一个节点认为某个节点 pfail 了，那么会在 gossip ping 消息中，ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成 fail。
		从节点过滤:
			对宕机的 master node，从其所有的 slave node 中，选择一个切换成 master node。
			检查每个 slave node 与 master node 断开连接的时间，如果超过了 cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成 master。
		从节点选举:
			每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset 越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。
			所有的 master node 开始 slave 选举投票，给要进行选举的 slave 进行投票，如果大部分 master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master。
		
	3).为什么Redis集群有16384个槽：
		https://www.cnblogs.com/rjzheng/p/11430592.html

3、redis 的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？什么是多路复用，原理是什么？
	首先，为什么要持久化：
		宕机后重启保证数据不丢失，也就是灾难恢复、数据恢复，如果丢失会出现什么问题？大量的请求过来，缓存全部无法命中，在 redis 里根本找不到数据，这个时候就死定了，出现缓存雪崩问题。一下 mysql 承接高并发，然后就挂了...
	1).持久化有哪几种方式：
		持久化机制有两种，第一种是快照(DDB snapshot)，第二种是 AOF 日志，以 append-only 的模式写入一个日志文件中。快照是一次全量备份，AOF 日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，
		而 AOF 日志记录的是内存数据修改的指令记录文本。 AOF 日志在长期的运行过程中会变的无比庞大，数据库重启时需要加载 AOF 日志进行指令重放，这个时间就会无比漫长。所以需要定期进行 AOF 重写，给 AOF 日志进行瘦身。

	2).不同的持久化机制都有什么优缺点:
		RDB 快照： 
			a).通过开启子进程的方式进行的，它是一个比较耗资源的操作。遍历整个内存，大块写磁盘会加重系统负载。
			b).RDB 会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，
				比如说 Amazon 的 S3 云服务上去，在国内可以是阿里云的 ODPS 分布式存储上，以预定好的备份策略来定期备份 redis 中的数据。
			c).RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
			d).相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
			e).如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，
				那么会丢失最近 5 分钟的数据。
			f).RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
		AOF：
			fsync 是一个耗时的 IO 操作，它会降低 Redis 性能，同时也会增加系统 IO 负担。
			a).AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
			b).AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
			c).AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。
				在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
			d).AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用 flushall 命令清空了所有数据，只要这个时候后台 rewrite 还没有发生，
				那么就可以立即拷贝 AOF 文件，将最后一条 flushall 命令给删了，然后再将该 AOF 文件放回去，就可以通过恢复机制，自动恢复所有数据。
			e).对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
			f).AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件，当然，每秒一次 fsync，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）
			g).以前 AOF 发生过 bug，就是通过 AOF 记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似 AOF 这种较为复杂的基于命令日志 / merge / 回放的方式，
				比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug，因此每次 rewrite 并不是基于旧的指令日志进行 merge 的，
				而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
			
			通常 Redis 的主节点是不会进行持久化操作，持久化操作主要在从节点进行。从节点是备份节点，没有来自客户端请求的压力，它的操作系统资源往往比较充沛。
		但是如果出现网络分区，从节点长期连不上主节点，就会出现数据不一致的问题，特别是在网络分区出现的情况下又不小心主节点宕机了，那么数据就会丢失，所以在生产环境要
		做好实时监控工作，保证网络畅通或者能快速修复。另外还应该再增加一个从节点以降低网络分区的概率，只要有一个从节点数据同步正常，数据也就不会轻易丢失。

		混合持久化：
			重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。
			混合持久化将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
			于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。
		
	3).持久化机制具体底层是如何实现的:
		RDB 实现原理：
			在服务线上请求的同时， Redis 还需要进行内存快照，内存快照要求 Redis 必须进行文件 IO 操作，可文件 IO 操作是不能使用多路复用 API。
			这意味着单线程同时在服务线上的请求还要进行文件 IO 操作，文件 IO 操作会严重拖垮服务器请求的性能。还有个重要的问题是为了不阻塞线上的业务，就需要边持久化边响应客户端请求。
			持久化的同时，内存数据结构还在改变，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它给删掉了，还没持久化完呢，这尼玛要怎么搞？
			Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化。
			fork(多进程)：
					持久化时会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。
				这时可以将父子进程想像成一个连体婴儿，共享身体。这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。
					子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。
				这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。
				这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。
					随着父进程修改操作的持续进行，越来越多的共享页面被分离出来，内存就会持续增长。但是也不会超过原有数据内存的 2 倍大小。另外一个 Redis 实例里冷数据占的比例往往是比较高的，
				所以很少会出现所有的页面都会被分离，被分离的往往只有其中一部分页面。每个页面的大小只有 4K，一个 Redis 实例里面一般都会有成千上万的页面。子进程因为数据没有变化，
				它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。
		AOF 实现原理：
			AOF 日志存储的是 Redis 服务器的顺序指令序列， AOF 日志只记录对内存进行修改的指令记录。（重放）
			Redis 会在收到客户端修改指令后，先进行参数校验，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是先存到磁盘，然后再执行指令。这样即使遇到突发宕机，已经存储到 AOF 日志的指令进行重放一下就可以恢复到宕机前的状态。
			长期运行——>AOF 日志文件增长——>宕机重启——>重放耗时——>长时无法对外提供服务，所以需要对 AOF 日志瘦身。
			AOF 重写：
					Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。
				序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。
			fsync：
					AOF 日志是以文件的形式存在的，当程序对 AOF 日志文件进行写操作时，实际上是将内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回到磁盘
				的。这就意味着如果机器突然宕机， AOF 日志内容可能还没有来得及完全刷到磁盘中，这个时候就会出现日志丢失。
					Linux 的 glibc 提供了 fsync(int fd)函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。但是 fsync 是一个
				磁盘 IO 操作，它很慢！如果 Redis 执行一条指令就要 fsync 一次，那么 Redis 高性能的地位就不保了。所以在生产环境的服务器中， Redis 通常是每隔 1s 左右执行一次 fsync 操作，周期 1s 是可以配置的。
				这是在数据安全性和性能之间做了一个折中，在保持高性能的同时，尽可能使得数据少丢失。

	4).什么是多路复用，原理是什么:
		https://www.jianshu.com/p/dfd940e7fca2

4.Redis的同步机制了解么？
		主从复制是 Redis 分布式的基础， Redis 的高可用离开了主从复制将无从进行。Redis 的集群模式，都依赖于主从复制。不过复制功能也不是必须的，如果你将 Redis 只用来做缓存，跟 memcache 一样来对
	待，也就无需要从库做备份，挂掉了重新启动一下就行。但是只要你使用了 Redis 的持久化功能，就必须认真对待主从复制，它是系统数据安全的基础保障。很多企业都没有使用到 Redis 的集群，但是至少都做了主从。
	分布式系统的理论基石——CAP 原理：
		C - Consistent，         一致性
		A - Availability，       可用性
		P - Partition tolerance，分区容忍性
			分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫着「网络分区」。
		在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的
		数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。
			一句话概括 CAP 原理就是——网络分区发生时，一致性和可用性两难全。
	最终一致：
			Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足「一致性」要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节
		点依旧可以正常对外提供修改服务，所以 Redis 满足「可用性」。Redis 保证「最终一致性」，从节点会努力追赶主节点，最终从节点的状态会和主节点
		的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。
	主从同步：
		增量同步：
				Redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，
			一边向主节点反馈自己同步到哪里了 (偏移量)。
				因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer中。 Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。
				如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时， Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉了，
			从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制 —— 快照同步。
		快照同步：
				快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当前内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。从节点将快
			照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。
				在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆
			盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以务必配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。
	从从同步：
		从从同步功能是 Redis 后续版本增加的功能，为了减轻主库的同步负担。
	增加从节点：
		当从节点刚刚加入到集群时，它必须先要进行一次快照同步，同步完成后再继续进行增量同步。
	无盘复制：
			主节点在进行快照同步时，会进行很重的文件 IO 操作，所谓无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序
		列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。
	Wait 指令：
		Redis 的复制是异步进行的， wait 指令可以让异步复制变身同步复制，确保系统的强一致性 (不严格)。 wait 指令是 Redis3.0 版本以后才出现的。

5.Pipeline有什么好处，为什么要用pipeline？
	使用 pipeline, 可以使多个连续的写操作和多个连续的读操作总共只会花费一次网络来回，就好比连续的 write（request）操作合并了，连续的 read（response） 操作也合并了一样。
	服务器根本没有任何区别对待，还是收到一条消息，执行一条消息，回复一条消息的正常的流程。客户端通过对管道中的指令列表改变读写顺序就可以大幅节省 IO 时间。
	> redis-benchmark -t set -P 2 -q # 管道压力测试。选项 -P 参数（可选），它表示单个管道内并行的请求数量，如果继续增 -P 参数QPS不再提升，说明 Redis 的单线程 CPU 已经飙到了 100%。
	连续的 write 操作根本就没有耗时，之后第一个 read 操作会等待一个网络的来回开销，然后所有的响应消息就都已经回送到内核的读缓冲了，后续的 read 操作直接就可以从缓冲拿到结果，瞬间就返回了

6.redis特点？
	线程 IO 模型:
		Redis 是个单线程程序！Nginx 也是单线程。因为它所有的数据都在内存中，所有的运算都是内存级别的运算。
		Redis 单线程如何处理那么多的并发客户端连接？
			非阻塞 IO：
					当我们调用套接字的读写方法，默认它们是阻塞的，比如 read 方法要传递进去一个参数n，表示读取这么多字节后再返回，如果没有读够线程就会卡在那里，直到新的数据到来或者
				连接关闭了， read 方法才可以返回，线程才能继续处理。而 write 方法一般来说不会阻塞，除非内核为套接字分配的写缓冲区已经满了， write 方法就会阻塞，直到缓存区中有空闲空间挪出来了。
					非阻塞 IO 在套接字对象上提供了一个选项 Non_Blocking，当这个选项打开时，读写方法不会阻塞，而是能读多少读多少，能写多少写多少。能读多少取决于内核为套接字分配的
				读缓冲区内部的数据字节数，能写多少取决于内核为套接字分配的写缓冲区的空闲空间字节数。读方法和写方法都会通过返回值来告知程序实际读写了多少字节。
				有了非阻塞 IO 意味着线程在读写 IO 时可以不必再阻塞了，读写可以瞬间完成然后线程可以继续干别的事了。
			事件轮询 (多路复用)：
				Redis 是一个事件驱动的内存数据库，服务器需要处理两种类型的事件：文件事件、时间事件。
				Redis 基于 Reactor 模式开发了自己的事件处理器。
					如： （fd、fd、fd、fd、fd、fd...）——> I/O 多路复用模块 ——> 事件分发器 ——> (链接应答处理器、命令请求处理器、命令回复处理器...)
					“I/O 多路复用模块”会监听多个 FD ，当这些FD产生 accept，read，write 或 close 的文件事件。会向“文件事件分发器（dispatcher）”传送事件。
				文件事件分发器（dispatcher）在收到事件之后，会根据事件的类型将事件分发给对应的 handler。
				I/O 多路复用模块：
					Redis 的 I/O 多路复用模块，其实是封装了操作系统提供的 select，epoll，avport 和 kqueue 这些基础函数。向上层提供了一个统一的接口，屏蔽了底层实现的细节。
					一般而言 Redis 都是部署到 Linux 系统上，所以我们就看看使用 Redis 是怎么利用 linux 提供的 epoll 实现I/O 多路复用。
				事件分发器（dispatcher）:
					根据不同的事件类型调用不同的事件处理器，将不同的事件分别分发给了读事件和写事件。
				文件事件处理器的类型：
					Redis 有大量的事件处理器类型，我们就讲解处理一个简单命令涉及到的三个处理器：
						acceptTcpHandler 连接应答处理器，负责处理连接相关的事件，当有client 连接到Redis的时候们就会产生 AE_READABLE 事件。引发它执行。
						readQueryFromClinet 命令请求处理器，负责读取通过 sokect 发送来的命令。
						sendReplyToClient 命令回复处理器，当Redis处理完命令，就会产生 AE_WRITEABLE 事件，将数据回复给 client。
	通信协议：
			Redis 的作者认为数据库系统的瓶颈一般不在于网络流量，而是数据库自身内部逻辑处理上。所以即使 Redis 使用了浪费流量的文本协议，依然可以取得极高的访问性能。 Redis
		将所有数据都放在内存，用一个单线程对外提供服务，单个节点在跑满一个 CPU 核心的情况下可以达到了 10w/s 的超高 QPS。
			RESP(Redis Serialization Protocol)，RESP 是 Redis 序列化协议的简写。它是一种直观的文本协议，优势在于实现异常简单，解析性能极好。
			Redis 协议将传输的结构数据分为 5 种最小单元类型，单元结束时统一加上回车换行符号\r\n。
				a、 单行字符串 以 + 符号开头。
				b、 多行字符串 以 $ 符号开头，后跟字符串长度。
				c、 整数值 以 : 符号开头，后跟整数的字符串形式。
				d、 错误消息 以 - 符号开头。
				e、 数组 以 * 号开头，后跟数组的长度。
				如：
					单行字符串 hello world > +hello world\r\n
					多行字符串 hello world > $11\r\nhello world\r\n # 多行字符串当然也可以表示单行字符串。
					整数 1024 > :1024\r\n
					错误 参数类型错误 > -WRONGTYPE Operation against a key holding the wrong kind of value
					数组 [1,2,3] > *3\r\n:1\r\n:2\r\n:3\r\n
					NULL 用多行字符串表示，不过长度要写成-1 > $-1\r\n
					空串 用多行字符串表示，长度填 0 > $0\r\n\r\n # 注意这里有两个\r\n。为什么是两个? 因为两个\r\n 之间,隔的是空串。
				客户端 -> 服务器：
					客户端向服务器发送的指令只有一种格式，多行字符串数组。比如一个简单的 set 指令set author codehole 会被序列化成下面的字符串。
						> *3\r\n$3\r\nset\r\n$6\r\nauthor\r\n$8\r\ncodehole\r\n
				服务器 -> 客户端：
					服务器向客户端回复的响应要支持多种数据结构，所以消息响应在结构上要复杂不少。不过再复杂的响应消息也是以上 5 中基本类型的组合。

	内存回收机制：
		惰性删除和定时任务删除:
			惰性删除:
				当客户端进行某个 key 的get 访问，该key被设置了过期时间，如果此时 get 操作的时候 key 过期了，此时 Redis 将会针对该 key 占用的空间进行回收。
				优点：该方式采用用户访问的方式进行空间回收，无需维护 key 的 TTL 链表数据。
				缺点：如果存在大量已过期的 key 但是长时间内用户一直没有进行 get 方法，会导致过期 key 堆积在内存中，产生内存泄漏。
			定时任务删除：
				Redis 内部维护一个定时任务，每秒执行10次。定时随机的进行过期key的内存回收。
			
			当你删除了 1GB 的 key 后，再去观察内存，你会发现内存变化不会太大。原因是操作系统回收内存是以页为单位，如果这个页上只要有一个 key
		还在使用，那么它就不能被回收。 Redis 虽然删除了 1GB 的 key，但是这些 key 分散到了很多页面中，每个页面都还有其它 key 存在，这就导致了内存不会立即被回收。

	Sentinel：



6.5.scan 的用法？
	复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程;
	服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;
	返回的结果可能会有重复，需要客户端去重复，这点非常重要;
	遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的;
	单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零;
	基本用法：
		> scan 0 match key99* count 1000 # scan 参数提供了三个参数，第一个是 cursor 整数值，第二个是 key 的正则模式，第三个是遍历的 limit hint。
		第一次遍历时， cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。
		scan 指令返回的游标就是第一维数组的位置索引，我们将这个位置索引称为槽 (slot)。
	scan 遍历顺序:
		它不是从第一维数组的第 0 位一直遍历到末尾，而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏。
		普通加法和高位进位加法的区别:高位进位法从左边加，进位往右边移动，同普通加法正好相反。但是最终它们都会遍历所有的槽位并且没有重复。
		rehash 就是将元素的hash 值对数组长度进行取模运算，因为长度变了，所以每个元素挂接的槽位可能也发生了变化。又因为数组的长度是 2^n 次方，所以取模运算等价于位与操作。
			a mod 8 = a & (8-1) = a & 7
			a mod 16 = a & (16-1) = a & 15
			a mod 32 = a & (32-1) = a & 31
			这里的 7, 15, 31 称之为字典的 mask 值， mask 的作用就是保留 hash 值的低位，高位都被设置为 0。
			假设当前的字典的数组长度由 8 位扩容到 16 位，那么 3 号槽位 011 将会被 rehash到 3 号槽位和 11 号槽位，也就是说该槽位链表中大约有一半的元素还是 3 号槽位，其它
		的元素会放到 11 号槽位， 11 这个数字的二进制是 1011，就是对 3 的二进制 011 增加了一个高位。
	scan 指令是一系列指令，除了可以遍历所有的 key 之外，还可以对指定的容器集合进行遍历。比如 zscan 遍历 zset 集合元素， hscan 遍历 hash 字典的元素、 sscan 遍历 set 集合的元素。

	大 key 扫描：
			一个很大的hash，一个很大的 zset 经常会形成很大的对象。这样的对象对 Redis 的集群数据迁移带来了很大的问题，因为在集群环境下，如果某个 key 太大，会数据导致迁移卡顿。另外在内存分配
		上，如果一个 key 太大，那么当它需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果这个大 key 被删除，内存会一次性回收，卡顿现象会再一次产生。
			如果你观察到 Redis 的内存大起大落，这极有可能是因为大 key 导致的。
			> redis-cli -h 127.0.0.1 -p 7001 --bigkeys -i 0.1 # 上面这个指令每隔 100 条 scan 指令就会休眠 0.1s， ops 就不会剧烈抬升，但是扫描的时间会变长。

7.Redis 能用来做什么？ 
	分布式锁
	缓存
	延迟队列 zset (消息序列化为 value，处理时间置为 score，多个线程轮询取 value 进行业务处理)
	每个人的每天签到记录 位图（setbit、getbit），如一年 365 天，每天的签到记录只占据一个位，365 天就是 365 个位， 46 个字节 (一个稍长一点的字符串) 就可以完全容纳下
		位图统计指令 bitcount 和位图查找指令 bitpos， bitcount 用来统计指定位置范围内 1 的个数， bitpos 用来查找指定范围内出现的第一个 0 或 1。
		bitfield：可以一次进行多个位的操作，> bitfield w get u4 0 # 从第一个位开始取 4 个位，结果是无符号数 (u)
	解决统计问题 (HyperLogLog)
		HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%，这样的精确度已经可以满足 UV 统计需求。
		三个指令 pfadd、 pfcount 和 pfmerge，一个是增加计数，一个是获取计数，再一个是将多个 pf 计数值累加在一起形成一个新的 pf 值，比如在网站中我们有两个内容差不多的页面，运营说需要这两个页面的数据进行合并。
		其中页面的 UV 访问量也需要合并，那这个时候 pfmerge 就可以派上用场了。
			>  pfadd codehole user1
			>  pfcount codehole
	允许有稍微误差的去重 （布隆过滤器）
		当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。
		布隆过滤器能准确过滤掉那些已经看过的内容，那些没有看过的新内容，它也会过滤掉极小一部分 (误判)，但是绝大多数新内容它都能准确识别。这样就可以完全保证推荐给用户的内容都是无重复的。
		基本使用：
				有二个基本指令， bf.add 添加元素， bf.exists 查询元素是否存在，它的用法和 set 集合的 sadd 和 sismember 差不多。注意 bf.add 只能一次添加一个元素，如果想要
			一次添加多个，就需要用到 bf.madd 指令。同样如果需要一次查询多个元素是否存在，就需要用到 bf.mexists 指令。
				error_rate 和 initial_size。错误率越低，需要的空间越大。 initial_size 参数表示预计放入的元素数量，当实际数量超出这个数值时，误判率会上升。
			默认的 error_rate 是 0.01，默认的 initial_size 是 100。 error_rate 越小，需要的存储空间就越大。
		原理：
				每个布隆过滤器对应到 Redis 的数据结构里面就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
			向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。
			再把位数组的这几个位置都置为 1 就完成了 add 操作。
				当实际元素开始超出初始化大小时，应该对布隆过滤器进行重建，重新分配一个 size 更大的过滤器，再将所有的历史元素批量 add 进
			去 (这就要求我们在其它的存储器中记录所有的历史元素)。因为 error_rate 不会因为数量超出就急剧增加，这就给我们重建过滤器提供了较为宽松的时间。
		应用场景举例：
				在爬虫系统中，我们需要对 URL 进行去重，已经爬过的网页就可以不用爬了。但是URL 太多了，几千万几个亿，如果用一个集合装下这些 URL 地址那是非常浪费空间的。这
			时候就可以考虑使用布隆过滤器。它可以大幅降低去重存储消耗，只不过也会使得爬虫系统错过少量的页面。
				布隆过滤器在 NoSQL 数据库领域使用非常广泛，我们平时用到的 HBase、 Cassandra还有 LevelDB、 RocksDB 内部都有布隆过滤器结构，布隆过滤器可以显著降低数据库的 IO
			请求数量。当用户来查询某个 row 时，可以先通过内存中的布隆过滤器过滤掉大量不存在的 row 请求，然后再去磁盘进行查询。
				邮箱系统的垃圾邮件过滤功能也普遍用到了布隆过滤器，因为用了这个过滤器，所以平时也会遇到某些正常的邮件被放进了垃圾邮件目录中，这个就是误判所致，概率很低。
	限流：
		简单限流：
				使用 zset 数据结构的 score 值来表示滑动时间窗口，只需要保留这个时间窗口内的行为数据，窗口之外的数据都可以砍掉。
			那这个 zset 的 value 填什么比较合适呢？它只需要保证唯一性即可，用 uuid 会比较浪费空间，那就改用毫秒时间戳吧。
				public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) {
					String key = String.format("hist:%s:%s", userId, actionKey);
					long nowTs = System.currentTimeMillis();
					Pipeline pipe = jedis.pipelined();
					pipe.multi();
					pipe.zadd(key, nowTs, "" + nowTs);
					// 移除时间窗口之前的行为记录，剩下的都是时间窗口内的
					pipe.zremrangeByScore(key, 0, nowTs - period * 1000);
					Response<Long> count = pipe.zcard(key);
					// 设置 zset 过期时间，避免冷用户持续占用内存
					// 过期时间应该等于时间窗口的长度，再多宽限 1s
					pipe.expire(key, period + 1);
					pipe.exec();
					pipe.close();
					return count.get() <= maxCount;
				}
			整体思路就是：每一个行为到来时，都维护一次时间窗口。将时间窗口外的记录全部清理掉，只保留窗口内的记录。zset 集合中只有 score 值非常重要， value 值没有特别的意义，只需要保证它是唯一的就可
			以了。因为这几个连续的 Redis 操作都是针对同一个 key 的，使用 pipeline 可以显著提升 Redis 存取效率。
		漏斗限流：
			void makeSpace() {
	            long nowTs = System.currentTimeMillis();
	            long deltaTs = nowTs - leakingTs; // 距离上一次漏水过去了多久
	            int deltaQuota = (int) (deltaTs * leakingRate);
	            if (deltaQuota < 0) { // 间隔时间太长，整数数字过大溢出
	                this.remainQuota = capacity;
	                this.leakingTs = nowTs;
	                return;
	            }
	            if (deltaQuota < 1) { // 腾出空间太小，最小单位是 1
	                return;
	            }
	            this.remainQuota += deltaQuota;
	            this.leakingTs = nowTs;
	            if (this.remainQuota > this.capacity) {
	                this.remainQuota = this.capacity;
	            }
	        }
	    Redis-Cell 限流：
	    	漏斗限流无法保证 redis 操作原子性，Redis 4.0 提供了一个限流 Redis 模块，它叫 redis-cell。该模块也使用了漏斗算法，并提供了原子的限流指令。该模块只有 1 条指令 cl.throttle。
	    	用法：
	    		> cl.throttle userId:actionkey 15 30 60 1 # 15-capacity 漏斗容量；30 60-30 operations / 60 seconds 漏水速率；1-need 1 quota（可选，默认为1）
					1) (integer) 0 # 0 表示允许， 1 表示拒绝
					2) (integer) 15 # 漏斗容量 capacity
					3) (integer) 14 # 漏斗剩余空间 left_quota
					4) (integer) -1 # 如果拒绝了，需要多长时间后再试(漏斗有空间了，单位秒)
					5) (integer) 2 # 多长时间后，漏斗完全空出来(left_quota==capacity，单位秒)
				在执行限流指令时，如果被拒绝了，就需要丢弃或重试。 cl.throttle 指令考虑的非常周到，连重试时间都帮你算好了，直接取返回结果数组的第四个值进行 sleep 即可，如果不想
			阻塞线程，也可以异步定时任务来重试。

	地理位置距离排序（GeoHash 算法）：
			GeoHash 算法将二维的经纬度数据映射到一维的整数，这样所有的元素都将在挂载到一条线上，距离靠近的二维坐标映射到一维后的点之间距离也会很接近。
			它将整个地球看成一个二维平面，然后划分成了一系列正方形的方格，就好比围棋棋盘。所有的地图元素坐标都将放置于唯一的方格中。方格越
		小，坐标越精确。然后对这些方格进行整数编码，越是靠近的方格编码越是接近。那如何编码呢？一个最简单的方案就是切蛋糕法。设想一个正方形的蛋糕摆在你面前，二刀下去均分
		分成四块小正方形，这四个小正方形可以分别标记为 00,01,10,11 四个二进制整数。然后对每一个小正方形继续用二刀法切割一下，这时每个小小正方形就可以使用 4bit 的二进制整数
		予以表示。然后继续切下去，正方形就会越来越小，二进制整数也会越来越长，精确度就会越来越高。
			编码之后，每个地图元素的坐标都将变成一个整数，通过这个整数可以还原出元素的坐标，整数越长，还原出来的坐标值的损失程度就越小。对于「附近的人」这个功能而言，损失的一点精确度可以忽略不计。
			GeoHash 算法会继续对这个整数做一次 base32 编码 (0-9,a-z 去掉 a,i,l,o 四个字母) 变成一个字符串。在 Redis 里面，经纬度使用 52 位的整数进行编码，放进了 zset 里面， zset的 value 是元素的 key， 
		score 是 GeoHash 的 52 位整数值。 zset 的 score 虽然是浮点数，但是对于 52 位的整数值，它可以无损存储。在使用 Redis 进行 Geo 查询时，我们要时刻想到它的内部结构实际上只是一个
		zset(skiplist)。通过 zset 的 score 排序就可以得到坐标附近的其它元素 (实际情况要复杂一些，不过这样理解足够了)，通过将 score 还原成坐标值就可以得到元素的原始坐标。
			> geoadd company 116.48105 39.996794 juejin
			> geoadd company 116.562108 39.787602 jd 116.334255 40.027400 xiaomi
			> geodist company juejin ireader km # 距离单位可以是 m、 km、 ml、 ft，分别代表米、千米、英里和尺。
			> geopos company juejin
			> geopos company juejin ireader
			> geohash company ireader # 使用这个编码值去 http://geohash.org/${hash}中进行直接定位，它是 geohash 的标准编码值。
			> georadiusbymember company ireader 20 km count 3 asc # 范围 20 公里以内最多 3 个元素按距离正排，它不会排除自身
			> georadiusbymember company ireader 20 km withcoord withdist withhash count 3 asc # 三个可选参数 withcoord withdist withhash 用来携带附加出参参数
			> georadius company 116.514202 39.905409 20 km withdist count 3 asc # 根据坐标值来查询附近的元素，这个指令更加有用，它可以根据用户的定位来计算「附近的车」，「附近的餐馆」等

8.数据结构都有哪些？特点是什么？
	存储界限 当集合对象的元素不断增加，或者某个 value 值过大，这种小对象存储也会被升级为标准结构。 Redis 规定在小对象存储结构的限制条件如下：
		hash-max-zipmap-entries 512 # hash 的元素个数超过 512 就必须用标准结构存储
		hash-max-zipmap-value 64 # hash 的任意元素的 key/value 的长度超过 64 就必须用标准结构存储
		list-max-ziplist-entries 512 # list 的元素个数超过 512 就必须用标准结构存储
		list-max-ziplist-value 64 # list 的任意元素的长度超过 64 就必须用标准结构存储
		zset-max-ziplist-entries 128 # zset 的元素个数超过 128 就必须用标准结构存储
		zset-max-ziplist-value 64 # zset 的任意元素的长度超过 64 就必须用标准结构存储
		set-max-intset-entries 512 # set 的整数元素个数超过 512 就必须用标准结构存储
	string (字符串)、 hash (哈希)、 list (列表)、 set (集合) 和 zset (有序集合)。
	RedisObject redis 对象头:
		所有的 Redis 对象都有下面的这个结构头:
			struct RedisObject {
				int4 type; // 4bits
				int4 encoding; // 4bits
				int24 lru; // 24bits
				int32 refcount; // 4bytes
				void *ptr; // 8bytes， 64-bit system
			} robj;
			不同的对象具有不同的类型 type(4bit)，同一个类型的 type 会有不同的存储形式 encoding(4bit)，为了记录对象的 LRU 信息，使用了 24 个 bit 来记录 LRU 信息。每个对
		象都有个引用计数，当引用计数为零时，对象就会被销毁，内存被回收。 ptr 指针将指向对象内容 (body) 的具体存储位置。这样一个 RedisObject 对象头需要占据 16 字节的存储空间。

	SDS 字符串结构：
		struct SDS {
			int8 capacity; // 1byte
			int8 len; // 1byte
			int8 flags; // 1byte
			byte[] content; // 内联数组，长度为 capacity
		}
		在字符串比较小时，SDS 对象头的大小是 capacity+3，至少是 3。意味着分配一个字符串的最小空间占用为 19 字节 (16+3)。

	intset 是紧凑的数组结构:
		struct intset<T> {
			int32 encoding; // 决定整数位宽是 16 位、 32 位还是 64 位
			int32 length; // 元素个数
			int<T> contents; // 整数数组，可以是 16 位、 32 位和 64 位
		}
		当 set 集合容纳的元素都是整数并且元素个数较小时， Redis 会使用 intset 来存储结合元素。 intset 是紧凑的数组结构，同时支持 16 位、 32 位和 64 位整数。
	
	ziplist 压缩列表：
		压缩列表是一块连续的内存空间，元素之间紧挨着存储，没有任何冗余空隙。zset 和 hash 容器对象在元素个数较少的时候，采用压缩列表 (ziplist) 进行存储。
		struct ziplist<T> {
			int32 zlbytes; // 整个压缩列表占用字节数
			int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量，用于快速定位到最后一个
			节点
			int16 zllength; // 元素个数
			T[] entries; // 元素内容列表，挨个挨个紧凑存储
			int8 zlend; // 标志压缩列表的结束，值恒为 0xFF
		}
		压缩列表为了支持双向遍历，所以才会有 ztail_offset 这个字段，用来快速定位到最后一个元素，然后倒着遍历。
		struct entry {
			int<var> prevlen; // 前一个 entry 的字节长度
			int<var> encoding; // 元素类型编码
			optional byte[] content; // 元素内容
		}
			entry 块随着容纳的元素类型不同，也会有不一样的结构。它的 prevlen 字段表示前一个 entry 的字节长度，当压缩列表倒着遍历时，需要通过这
		个字段来快速定位到下一个元素的位置。它是一个变长的整数，当字符串长度小于254(0xFE) 时，使用一个字节表示；如果达到或超出 254(0xFE) 那就使用 5 个字节来表示。
		第一个字节是 0xFE(254)，剩余四个字节表示字符串长度。
		级联更新：~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	quicklist 快速列表:
		struct quicklist {
			quicklistNode* head;
			quicklistNode* tail;
			long count; // 元素总数
			int nodes; // ziplist 节点的个数
			int compressDepth; // LZF 算法压缩深度
			...
		}
		struct quicklistNode {
			quicklistNode* prev;
			quicklistNode* next;
			ziplist* zl; // 指向压缩列表
			int32 size; // ziplist 的字节总数
			int16 count; // ziplist 中的元素数量
			int2 encoding; // 存储形式 2bit，原生字节数组还是 LZF 压缩存储
			...
		}
		quicklist 内部默认单个 ziplist 长度为 8k 字节，超出了这个字节数，就会新起一个ziplist。 ziplist 的长度由配置参数 list-max-ziplist-size 决定。
			因为普通的链表需要的附加指针空间太大，会比较浪费空间，而且会加重内存的碎片化。比如这个列表里存的只是 int 类型的数据，结构上还需要两个额外的指针 prev 和 next 。所以 Redis 将链表和 ziplist 
		结合起来组成了 quicklist。也就是将多个ziplist 使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

	a).字符串
		字符串是动态字符串，可修改，预分配冗余空间来减少内存的频繁分配，在内存中它是以字节数组的形式存在。
		如果 value 值是一个整数，还可以对它进行自增操作。自增是有范围的，它的范围是 signed long 的最大最小值，超过了这个值， Redis 会报错。那么编码是 int。
		扩容策略：
			当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。需要注意的是字符串最大长度为 512M。
		内部结构实现：
			Redis 的字符串有两种存储方式，在长度特别短时，使用 emb 形式存储 (embeded)，当长度超过 44 时，使用 raw 形式存储。
			可以通过命令：debug object key 查看 key 的 encoding (encoding:embstr)
			embstr 存储形式：
				RedisObject 对象头和 SDS 对象连续存在一起，使用 malloc 方法一次分配。
			raw 存储形式：
				需要两次 malloc，RedisObject 和 SDS 两个对象头在内存地址上一般是不连续的。
			而内存分配器 jemalloc/tcmalloc 等分配内存大小的单位都是 2、 4、 8、 16、 32、 64 等等，为了能容纳一个完整的 embstr 对象， jemalloc 最少会分配 32 字节的空间，如果字符
		串再稍微长一点，那就是 64 字节的空间。如果总体超出了 64 字节， Redis 认为它是一个大字符串，不再使用 emdstr 形式存储，而该用 raw 形式。
			SDS 结构体中的 content 中的字符串是以字节\0 结尾的字符串，之所以多出这样一个字节，是为了便于直接使用 glibc 的字符串处理函数，以及为了便于字符串的调试打印输出。留给 content 的长度
		最多只有 45(64-19) 字节了。字符串又是以\0 结尾，所以 embstr 最大能容纳的字符串长度就是 44。
	b).列表
		底层是链表，插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为O(n)。
		> lrange key 0 -1 #获取所有元素， O(n) 慎用。
		> ltrim books 1 0 #这其实是清空了整个列表，因为区间范围长度为负，ltrim 跟的两个参数 start_index 和 end_index 定义了一个区间，在这个区间内的值，ltrim 要保留，区间之外统统砍掉。我们可以通过 ltrim 来实现一个定长的链表，这一点非常有用。
		> lindex books 1 # O(n) 慎用 index=-1 表示倒数第一个元素，同样 index=-2 表示倒数第二个元素。
		列表底层存储的不是一个简单的 linkedlist，而是称之为快速链表 quicklist 的一个结构。首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是 ziplist，也即是压缩列表。
		它将所有的元素紧挨着一起存储，分配的是一块连续的内存。当数据量比较多的时候才会改成 quicklist。
	c).字典
		Redis 的字典的值只能是字符串，Redis为了高性能，不能堵塞服务，所以采用了渐进式 rehash 策略。
		同字符串一样，hash 结构中的单个子 key 也可以进行计数，它对应的指令是 hincrby，和 incr 使用基本一样： > hincrby key age 1
		如果数据量很小，key 和 value 会作为两个 entry 相邻存在一起 > object encoding hello # "ziplist"
		> hset books java "think in java"
		> hset books golang "concurrency in go"
		> hset books python "python cookbook"
		> hgetall books # key 和 value 间隔出现
		> hlen books
		> hget books java
		> hset books golang "learning go programming" # 因为是更新操作，所以返回 0
		> hmset books java "effective java" python "learning python" golang "modern golang programming" # 批量 set
		> hdel books java
		底层实现：
			struct RedisDb {
				dict* dict; // 所有 key 和 value 也组成了一个全局字典
				dict* expires; // 带过期时间的 key 集合也是一个字典
				...
			}
			dict 内部结构：
				struct dict {
					...
					dictht ht[2]; // 内部包含两个 hashtable，通常情况下只有一个 hashtable 是有值的。但是在dict 扩容缩容时，需要分配新的 hashtable，然后进行渐进式搬迁，
				}
				dictht 内部结构：
				struct dictht {
					dictEntry** table; // 二维
					long size; // 第一维数组的长度
					long used; // hash 表中的元素个数
					...
				}
			hash 函数：Redis 的字典默认的 hash 函数是siphash。 
			扩容条件：
					正常情况下， 当 hash 表中元素的个数等于第一维数组的长度时，就会开始扩容，扩容的新数组是原数组大小的 2 倍。不过如果 Redis 正在做 bgsave，为了减少内存页的过多分离 (Copy On Write)， 
				Redis 尽量不去扩容 (dict_can_resize)，但是如果 hash 表已经非常满了，元素的个数已经达到了第一维数组长度的 5 倍 (dict_force_resize_ratio)，说明 hash 表已经过于拥挤了，这个时候就会强制扩容。
			缩容条件：
				缩容的条件是元素个数低于数组长度的 10%。缩容不会考虑 Redis 是否正在做 bgsave。
	d).集合
		元素个数较少且存放元素都是整数的 set 集合，使用的是 intset 这个紧凑的整数数组结构：
				如果整数可以用 uint16 表示，那么 intset 的元素就是 16 位的数组，如果新加入的整数超过了 uint16 的表示范围，那么就使用 uint32 表示，如果新加入的元素超过了 uint32
			的表示范围，那么就使用 uint64 表示， Redis 支持 set 集合动态从 uint16 升级到 uint32，再升级到 uint64。
		如果 set 里存储的是字符串，那么 sadd 立即升级为 hashtable 结构。
		相当于 Java 语言里面的 HashSet，Java 中的 HashSet 继承自 HashMap，且 value 都指向同一个 Object。Redis 中的 set 的 value 都为 null。
		set 结构可以用来存储活动中奖的用户 ID，因为有去重功能，可以保证同一个用户不会中奖两次。
		Java 中 HashSet 可以保证不存在重复元素的原因：向 HashSet 中添加一个已经存在的元素时，新添加的集合元素将不会被放入 HashMap中，原来的元素也不会有任何改变，这也就满足了 Set 中元素不重复的特性。
		> sadd books python # 返回 1
		> sadd books python # 返回 0
		> sadd books java golang # 返回 2
		> smembers books # 注意顺序，和插入的并不一致，因为 set 是无序的
		> sismember books java # 查询某个 value 是否存在，返回 1，相当于 contains(o)
		> scard books # 获取长度相当于 count()
		> spop books # 弹出一个
	e).有序集合
			如果数据量很小，value 和 score 会作为两个 entry 相邻存在一起 > object encoding world # "ziplist"
			类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它需要一个 hash 结构来存储 value 和 score 的对应关系，另一方面需要提供按照 score 来排序的功能，还需要能够指定 score 的范围来获
		取 value 列表的功能，这就需要另外一个结构「跳跃列表」。因为 zset 要支持随机的插入和删除，所以它不好使用数组来表示。
		跳跃列表采取一个随机策略来决定新元素可以兼职到第几层:
			Redis 的跳跃表共有 64 层，意味着最多可以容纳 2^64 次方个元素。
			首先 L0 层肯定是 100% 了， L1 层只有 50% 的概率， L2 层只有 25% 的概率， L3层只有 12.5% 的概率，一直随机到最顶层 L31 层。绝大多数元素都过不了几层，只有极少数元素可以深入到顶层。
		列表中的元素越多，能够深入的层次就越深，能进入到顶层的概率就会越大。
			每一个 kv 块对应的结构如下面的代码中的 zslnode 结构，kv 之间使用指针串起来形成了双向链表结构，它们是有序排列的，从小到大。不同的 kv 层高可能不一样，层数越高的 kv 越少。
		同一层的 kv会使用指针串起来。每一个层元素的遍历都是从 kv header 出发。kv header 也是这个结构，只不过 value 字段是 null 值——无效的， score 是Double.MIN_VALUE，用来垫底的。 
			struct zslnode {
				string value;
				double score;
				zslnode*[] forwards; // 多层连接指针
				zslnode* backward; // 回溯指针
			}
				struct zsl {
				zslnode* header; // 跳跃列表头指针
				int maxLevel; // 跳跃列表当前的最高层
				map<string, zslnode*> ht; // hash 结构的所有键值对
			}
		查找过程：O(lg(n))
		插入过程
		删除过程
		更新过程：
			redis 的操作是：先删除这个元素，再插入这个元素，需要经过两次路径搜索。 
		如果 score 值都一样呢？
			zset 的排序元素不只看 score 值，如果 score 值相同还需要再比较 value 值 (字符串比较)。
		元素排名是怎么算出来的？
			Redis 在 skiplist 的 forward 指针上进行了优化，给每一个 forward 指针都增加了 span 属性， span 是「跨度」的意思，表示从前一个节点沿着当前层的 forward 指针跳到当前这个节
		点中间会跳过多少个节点。 Redis 在插入删除操作时会小心翼翼地更新 span 值的大小。
			这样当我们要计算一个元素的排名时，只需要将「搜索路径」上的经过的所有节点的跨度 span 值进行叠加就可以算出元素的最终 rank 值。

		应用场景举例：
			zset 可以用来存粉丝列表，value 值是粉丝的用户 ID，score 是关注时间。我们可以对粉丝列表按关注时间进行排序。
			zset 还可以用来存储学生的成绩，value 值是学生的 ID，score 是他的考试成绩。我们可以对成绩按分数进行排序就可以得到他的名次。
			> zadd books 9.0 "think in java" # 1
			> zadd books 8.9 "java concurrency" # 1
			> zadd books 8.6 "java cookbook" # 1
			> zrange books 0 -1 # 按 score 排序列出，参数区间为排名范围
				1) "java cookbook"
				2) "java concurrency"
				3) "think in java"
			> zrevrange books 0 -1 # 按 score 逆序列出，参数区间为排名范围
				1) "think in java"
				2) "java concurrency"
				3) "java cookbook"
			> zcard books # 相当于 count() 3
			> zscore books "java concurrency" # 获取指定 value 的 score "8.9000000000000004" 内部 score 使用 double 类型进行存储，所以存在小数点精度问题
			> zrank books "java concurrency" # 排名 1
			> zrangebyscore books 0 8.91 # 根据分值区间遍历 zset
				1) "java cookbook"
				2) "java concurrency"
			> zrangebyscore books -inf 8.91 withscores # 根据分值区间 (-∞, 8.91] 遍历 zset，同时返回分值。 inf 代表 infinite，无穷大的意思。
				1) "java cookbook"
				2) "8.5999999999999996"
				3) "java concurrency"
				4) "8.9000000000000004"
			> zrem books "java concurrency" # 删除 value 1
			> zrange books 0 -1
				1) "java cookbook"
				2) "think in java"

9.Redis 数据库内存数据满了，会宕机吗？
	在使用 Redis 的时候我们要配置 Redis 能使用的最大的内存大小，存到一定容量的时候会触发 Redis 的内存淘汰策略。如果不设置最大内存大小或者设置最大内存大小为0，在64位操作系统下不限制内存大小，在32位操作系统下最多使用3GB内存
	通过配置文件配置（redis.conf）：
		> maxmemory 100mb
	通过命令修改:
		> config set maxmemory 100mb
	淘汰策略（内存用完的时候触发）：
		noeviction(默认策略)：对于写请求不再提供服务，直接返回错误（DEL请求和部分特殊请求除外）
		allkeys-random：从所有 key 中随机淘汰数据
		volatile-random：从设置了过期时间的 key 中随机淘汰
		volatile-ttl：在设置了过期时间的 key 中，根据 key 的过期时间进行淘汰，越早过期的越优先被淘汰
		allkeys-lru：从所有 key 中使用 LRU 算法进行淘汰
		volatile-lru：从设置了过期时间的 key 中使用 LRU 算法进行淘汰
		volatile-lfu（Redis4.0新增）：在设置了过期时间的 key中使用 LFU 算法淘汰key
		allkeys-lfu（Redis4.0新增）：在所有的 key 中使用 LFU 算法淘汰数据
	LRU(Least Recently Used)：
		即最近最少使用，如果一个数据在最近一段时间没有被用到，那么将来被使用到的可能性也很小，所以就可以被淘汰掉。
	LFU（Least Frequently Used）：
			根据 key 的最近被访问的频率进行淘汰，很少被访问的优先被淘汰，被访问的多的则被留下来。
			一个 key 很久没有被访问到，只刚刚是偶尔被访问了一次，那么它就被认为是热点数据，不会被淘汰，而有些key将来是很有可能被访问到的则被淘汰了。如果使用LFU算法则不会出现这种情况，
		因为使用一次并不会使一个 key 成为热点数据。
	Redis为了实现近似LRU算法，给每个key增加了一个额外增加了一个24bit的字段，用来存储该key最后一次被访问的时间。
	Redis使用的是近似LRU算法，它跟常规的LRU算法还不太一样。近似LRU算法通过随机采样法淘汰数据，每次随机出5（默认）个key，从里面淘汰掉最近最少使用的key。
		Redis3.0对近似LRU算法进行了一些优化。新算法会维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中最小的时间才会放入池中，
	直到候选池被放满。当放满后，如果有新的key需要放入，则将池中最后访问时间最大（最近被访问）的移除。当需要淘汰的时候，则直接从池中选取最近访问时间最小（最久没被访问）的key淘汰掉就行。





###############################源码类#############################
1、你看过那些源码吗？ 
2、那你能讲讲 HashMap的实现原理吗？ 
3、HashMap什么时候会进行 rehash？
4、结合源码说说 HashMap在高并发场景中为什么会出现死循环？ 
5、JDK1.8中对 HashMap做了哪些性能优化？
6、HashMap和 HashTable有何不同？
7、HashMap 和 ConcurrentHashMap 的区别？ 
	https://swenfang.github.io/2018/06/03/Java%208%20ConcurrentHashMap%20%E6%BA%90%E7%A0%81%E8%A7%A3%E8%AF%BB/
	链表转红黑树的阈值为什么是8，而不是16等其他数量？

8、 ConcurrentHashMap和LinkedHashMap有什么区别？ 
9、为什么ConcurrentHashMap中的链表转红黑树的阀值是8？
10、还看过其他的源码吗？Spring的源码有了解吗？ 

11、SpringBoot 的源码呢？知道 starter 是怎么实现的吗？
	https://www.cnblogs.com/hjwublog/p/10332042.html

12、happens-before原则？
	对volatile域的写入操作happens-before于每一个后续对同一域的读操作。


############################## cookie 和 session ########################
	cookie 是浏览器保存在用户电脑上的一小段文本，通俗的来讲就是当一个用户通过 http 访问到服务器时，服务器会将一些 Key/Value 键值对返回给客户端浏览器，并给这些数据加上一些限制条件，
在条件符合时这个用户下次访问这个服务器时，数据通过请求头又被完整地给带回服务器，服务器根据这些信息来判断不同的用户。

	Session 是基于 Cookie 来工作的，同一个客户端每次访问服务器时，只要当浏览器在第一次访问服务器时，服务器设置一个id并保存一些信息(例如登陆就保存用户信息，视具体情况)，并把这个 id 通过 Cookie 存到客户端，
客户端每次和服务器交互时只传这个 id，就可以实现维持浏览器和服务器的状态，而这个ID通常是 NAME 为 JSESSIONID 的一个 Cookie。

	当浏览器第一次访问服务器时，服务器创建 Session 并将 SessionID 通过 Cookie 带给浏览器保存在客户端，同时服务器根据业务逻辑保存相应的客户端信息保存在 session 中；客户端再访问时上传 Cookie，
服务器得到 Cookie 后获取里面的 SessionID，来维持状态。


############################## 在一张表中,查询出一个字段相同,一个字段不同的记录 ###########################
比如表A中
字段1  字段2
2      43
3      65
2      68
1      92
用sql语句实现查询，查询出
2      43
2      68
这样结果

select distinct x.字段一,x.字段二
from a as x,a as Y
where x.字段一=y.字段一 and x.字段二!=y.字段二

############################# 深拷贝 和 浅拷贝 #############################








################################################# 算法与数据结构 #################################################
数组、链表、栈、队列、散列表、二叉树、堆、跳表、图、Trie树；10个算法：递归、排序、二分查找、搜索、哈希算法、贪心算法、分治算法、回溯算法、动态规划、字符串匹配算法。
1、数组：
	在进行数组的插入、删除操作时，为了保持内存数据的连续性，需要做大量的数据搬移，所以时间复杂度是O(n)。
	数组是适合查找操作，但是查找的时间复杂度并不为O(1)。即便是排好序的数组，你用二分查找，时间复杂度也是O(logn)。所以，正确的表述应该是，数组支持随机访问，根据下标随机访问的时间复杂度为O(1)。
2、链表：
	链表通过指针将一组零散的内存块串联在一起。其中，我们把内存块称为链表的“结点”。为了将所有的结点串起来，每个链表的结点除了存储数据之外，还需要记录链上的下一个结点的地址。
	链表又有单链表、双向链表和循环链表。
	单链表的插入、删除操作的时间复杂度是O(1)。
	在实际的软件开发中，从链表中删除一个数据无外乎这两种情况：
		一、删除结点中“值等于某个给定值”的结点；
		一、删除给定指针指向的结点。
		对于第一种情况，不管是单链表还是双向链表，为了查找到值等于给定值的结点，都需要从头结点开始一个一个依次遍历对比，直到找到值等于给定值的结点，然后再通过我前面讲的指针操作将其删除。
			尽管单纯的删除操作时间复杂度是O(1)，但遍历查找的时间是主要的耗时点，对应的时间复杂度为O(n)。根据时间复杂度分析中的加法法则，删除值等于给定值的结点对应的链表操作的总时间复杂度为O(n)。
		对于第二种情况，我们已经找到了要删除的结点，但是删除某个结点q需要知道其前驱结点，而单链表并不支持直接获取前驱结点，所以，为了找到前驱结点，我们还是要从头结点开始遍历链表，直到p->next=q，说明p是q的前驱结点。
			但是对于双向链表来说，这种情况就比较有优势了。因为双向链表中的结点已经保存了前驱结点的指针，不需要像单链表那样遍历。所以，针对第二种情况，单链表删除操作需要O(n)的时间复杂度，而双向链表只需要在O(1)的时间复杂度内就搞定了！
			同理，如果我们希望在链表的某个指定结点前面插入一个结点，双向链表比单链表有很大的优势。双向链表可以在O(1)时间复杂度搞定，而单向链表需要O(n)的时间复杂度。你可以参照我刚刚讲过的删除操作自己分析一下
3、栈：
	后进者先出，先进者后出，这就是典型的“栈”结构。
	应用：
		函数调用栈：
			作系统给每个线程分配了一块独立的内存空间，这块内存被组织成“栈”这种结构,用来存储函数调用时的临时变量。每进入一个函数，就会将临时变量作为一个栈帧入栈，当被调用函数执行完成，返回之后，将这个函数对应的栈帧出栈。
		表达式求值中的应用：
			编译器就是通过两个栈来实现的。其中一个保存操作数的栈，另一个是保存运算符的栈。我们从左向右遍历表达式，当遇到数字，我们就直接压入操作数栈；当遇到运算符，就与运算符栈的栈顶元素进行比较。
			如果比运算符栈顶元素的优先级高，就将当前运算符压入栈；如果比运算符栈顶元素的优先级低或者相同，从运算符栈中取栈顶运算符，从操作数栈的栈顶取2个操作数，然后进行计算，再把计算完的结果压入操作数栈，继续比较。
			可以试验一下表达式：3 + 5 * 8 - 6这个表达式的计算过程。
		浏览器的前进、后退功能：
			我们使用两个栈，X和Y，我们把首次浏览的页面依次压入栈X，当点击后退按钮时，再依次从栈X中出栈，并将出栈的数据依次放入栈Y。当我们点击前进按钮时，我们依次从栈Y中取出数据，放入栈X中。当栈X中没有数据时，那就说明没有页面可以继续后退浏览了。
			当栈Y中没有数据，那就说明没有页面可以点击前进按钮浏览了。
			如果栈X中现在有 A、B（A在栈最底端），栈Y中现在有 C，现在用户又浏览了页面 D，因为栈Y中最顶端的页面不是 D，所以把 D 放入栈X，页面 C 就无法再通过前进、后退按钮重复查看了，然后把栈 Y 清空。
		括号匹配中的应用：
			我们用栈来保存未匹配的左括号，从左到右依次扫描字符串。当扫描到左括号时，则将其压入栈中；当扫描到右括号时，从栈顶取出一个左括号。如果能够匹配，比如“(”跟“)”匹配，“[”跟“]”匹配，“{”跟“}”匹配，则继续扫描剩下的字符串。
			如果扫描的过程中，遇到不能配对的右括号，或者栈中没有数据，则说明为非法格式。
			当所有的括号都扫描完成之后，如果栈为空，则说明字符串为合法格式；否则，说明有未匹配的左括号，为非法格式。
4、队列
		队列最大的特点就是先进先出，主要的两个操作是入队和出队。
		跟栈一样，它既可以用数组来实现，也可以用链表来实现。用数组实现的叫顺序队列，用链表实现的叫链式队列。
		特别是长得像一个环的循环队列。
		在数组实现队列的时候，会有数据搬移操作，要想解决数据搬移的问题，我们就需要像环一样的循环队列。
		要想写出没有bug的循环队列实现代码，关键要确定好队空和队满的判定条件。
		除此之外，我们还讲了几种高级的队列结构，阻塞队列、并发队列，底层都还是队列这种数据结构，只不过在之上附加了很多其他功能。阻塞队列就是入队、出队操作可以阻塞，并发队列就是队列的操作多线程安全。






################################################# C——malloc()和calloc() #################################################
malloc和calloc函数在参数个数、初始化内存空间、函数返回值上有区别：
	1、参数个数上的区别：
		malloc函数：malloc(size_t size)函数有一个参数，即要分配的内存空间的大小。
		calloc函数：calloc(size_t numElements,size_t sizeOfElement)有两个参数，分别为元素的数目和每个元素的大小，这两个参数的乘积就是要分配的内存空间的大小。
	2、初始化内存空间上的区别：
		malloc函数：不能初始化所分配的内存空间，在动态分配完内存后，里边数据是随机的垃圾数据。
		calloc函数：能初始化所分配的内存空间，在动态分配完内存后，自动初始化该内存空间为零。
	3、函数返回值上的区别：
		malloc函数：函数返回值是一个对象。
		calloc函数：函数返回值是一个数组。


===============================================================================================================================
===============================================================================================================================
===============================================================================================================================
java高频面试题如下：
java基础
	1、Arrays.sort 实现原理和 Collections 实现原理
		Arrays.sort实现原理：
			Arrays.sort 底层通过 DualPivotQuicksort.sort (双轴快速排序) 实现，即快速排序。与归并排序比较适合大规模的数据排序。
			数组小于 47 时 使用插入排序，小于 286 时使用双轴快排（切片-整合，改进版快排）。
			大于 286 时评估数组的无序程度，大的话使用改进版归并排序，小的话使双轴快排。
		Collections 实现原理：
			排序：
				-----------------------
				public static <T extends Comparable<? super T>> void sort(List<T> list) { // T 需要实现 Comparable
			        list.sort(null);
			    }
			    public static <T> void sort(List<T> list, Comparator<? super T> c) { // 需要自定义比较 工具类
				    list.sort(c);
				}
				底层通过 List 的方法 default void sort(Comparator<? super E> c) {...} 实现，
				而 List 的 该方法通过 Arrays 的 public static <T> void sort(T[] a, Comparator<? super T> c) {...} 实现。
				public static <T> void sort(T[] a, Comparator<? super T> c) {
					if (c == null) {
			            sort(a);
			        } else {
			            if (LegacyMergeSort.userRequested)
			            	// 使用归并排序
			                legacyMergeSort(a, c);
			            else
			            	// 
			                TimSort.sort(a, 0, a.length, c, null, 0, 0);
			        }
			    }
	2、foreach 和 while 的区别(编译之后)
		foreach 其实是通过迭代器 Iterator 来实现的，编译后：
			ArrayList<String> list = new ArrayList();
			Iterator var2 = list.iterator();
			while(var2.hasNext()) {
				String item = (String)var2.next();
				System.out.println(item);
			}

		for循环再某些方面要更优一些如无限循环 while(true) for(;;)
		　　编译前              编译后
		　　while (1)；        mov eax,1
		　　test eax,eax
		　　je foo+23h
		　　jmp foo+18h

		　　编译前              编译后
		　　for (；；)；          jmp foo+23h
		　　从编译后的结果我们可以看出for的指令少，而且没有判断，显然更快.
	3、线程池的种类，区别和使用场景分析
		一、ThreadPoolExecutor：
			a.类继承关系：
				Executor:
					只有一个方法 void execute(Runnable command); 并且实现是在 ThreadPoolExecutor 完成的，submit 系列方法在 AbstractExecutorService 完成实现。
					-ExecutorService:
						-AbstractExecutorService:
							-ThreadPoolExecutor:
								线程拒绝策略 RejectedExecutionHandler:
									void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
									实现类(均为 RejectedExecutionHandler 的静态内部类)：
										CallerRunsPolicy
											由调用线程（提交任务的线程）直接执行此任务，如在 main 方法里开启了过多的线程，那么多出来的线程将由 main 线程来直接执行。
										AbortPolicy
											默认策略，丢弃任务并抛出 RejectedExecutionException 异常。如果是比较关键的业务，推荐使用此拒绝策略，这样子在系统不能承载更大的并发量的时候，能够及时的通过异常发现。
										DiscardPolicy
											丢弃（方法实现内部不做任何处理）静默丢弃不抛出异常。非关键业务可以使用。
										DiscardOldestPolicy
											丢弃队列最前面的任务，然后重新提交被拒绝的任务。得根据实际业务是否允许丢弃老任务来认真衡量。
			b.线程池状态含义：
				RUNNING     接受新任务并且处理阻塞队列里的任务
				SHUTDOWN    拒绝新任务但是处理阻塞队列里的任务
				STOP        拒绝新任务并且抛弃阻塞队列里的任务，同时会中断正在处理的任务
				TIDYING     所有任务都执行完（包含阻塞队列里面的任务）后当前线程池活动线程数为 0，将要调用 terminated 方法
				TERMINATED  终止状态。 terminated 方法调用完成以后的状态
			c.线程池状态转换：
				RUNNING -> SHUTDOWN          显式调用 shutdown（）方法，或者隐式调用了 finalize() 方法里面的 shutdown（）方法 
				RUNNING 或 SHUTDOWN -> STOP  显式调用 shutdownNow（）方法时
				SHUTDOWN -> TIDYING          当线程池和任务队列都为空时
				STOP -> TIDYING              当线程池为空时
				TIDYING -> TERMINATED        当 terminated() hook 方法执行完成时
			d.表示状态的字段
				// 高 3 位用来表示线程池状态，低 29 位用来表示线程个数。默认是 RUNNING 状态，线程个数为 0。
				private final Atomicinteger ctl =new Atomicinteger(ctlOf(RUNNING , 0));
				// 线程个数掩码位数，并不是所有平台的 int 类型都是 32 位的，所以准确地说，是具体平台下 Integer 的二进制位数 -3 后的剩余位数所表示的数才是线程的个数
				private static final int COUNT_BITS = Integer.SIZE - 3;
				// 线程最大个数（低29位） 00011111111111111111111111111111
				private static final int CAPACITY(1 < COUNT_BITS) - 1;

				//（高 3 位） : 111 00000000000000000000000000000
				private static final int RUNNING    = -1 << COUNT_BITS;
				// (高 3 位） : 000 00000000000000000000000000000
				private static final int SHUTDOWN   =  0 << COUNT_BITS;
				//（高 3 位） : 001 00000000000000000000000000000
				private static final int STOP       =  1 << COUNT_BITS;
				//（高 3 位） : 010 00000000000000000000000000000
				private static final int TIDYING    =  2 << COUNT_BITS;
				//（高 3 位） : 011 00000000000000000000000000000
				private static final int TERMINATED =  3 << COUNT_BITS;

				// 获取高 3位（运行状态）
				private static int runStateOf(int c)     { return c & ~CAPACITY; }
				// 获取低29位（线程个数）
				private static int workerCountOf(int c)  { return c & CAPACITY; }
				// 计算 ctl 新值（线程状态与线程个数）
				private static int ctlOf(int rs, int wc) { return rs | wc; }

				// 保存任务的队列
				private final BlockingQueue<Runnable> workQueue;

				// 如果当前线程池中的线程数量比核心线程数量多，并且是闲置状态，则这些闲置的线程能存活的最大时间
				private volatile long keepAliveTime;

				// 控制新增 Worker 线程操作的原子性
				private final ReentrantLock mainLock = new ReentrantLock();

				// 锁对应的条件队列，在线程调用 awaitTermination 时用来存放阻塞的线程
				private final Condition termination = mainLock.newCondition();

				// 线程池所有的工作线程，只有在拿到 mainLock 时才能访问
				private final HashSet<Worker> workers = new HashSet<Worker>();
			e.JDK中的线程池类型（来自 Executors 中的方法）：
				要么使用默认的 DefaultThreadFactory （来自 Executors 中的静态类），要么自己定义 ThreadFactory。
				newFixedThreadPool
					队列是 LinkedBlockingQueue，长度是 Integer.MAX_VALUE，所以需要注意内存溢出的风险。 
				newSingleThreadExecutor
					队列是 LinkedBlockingQueue。
				newCachedThreadPool
					corePoolSize 为 0， maximumPoolSize = Integer.MAX_VALUE
					队列是 SynchronousQueue 创建一个按需创建线程的线程池，初始线程个数为 0，最多线程个数为 Integer.MAX_VALUE，并且阻塞队列为同步队列。 keeyAliveTime = 60，
					说明只要当前线程在 60s 内空闲则回收。这个类型的特殊之处在于，加入同步队列的任务会被马上执行，同步队列里面最多只有一个任务。
			f.Worker：
				Worker 继承 AQS 和 Runnable 接口，是具体承载任务的对象。 自己实现了简单不可重入独占锁，其中 state=0 表示锁未被获取状态，state=l 表示锁己经
				被获取的状态，state=-l 是创建 Worker 时默认的状态。
			g.源码分析（重要的方法）
				一、execute(Runnable command)：
					public void execute(Runnable command) {
				        if (command == null)
				            throw new NullPointerException();
				        int c = ctl.get();
				        // 如果 worker 数量比 corePoolSize 小，则尝试 command 参数作为第一个任务开启一个新线程
				        if (workerCountOf(c) < corePoolSize) {
				            if (addWorker(command, true))
				                return;
				            c = ctl.get();
				        }
				        // 如果当前线程池处于 RUNNING 状态，并且将当前任务添加到阻塞队列成功
				        if (isRunning(c) && workQueue.offer(command)) {
				            int recheck = ctl.get();
				            // 二次校验：到这里有可能线程池的状态己经变化了，非 RUNNING 状态下是要抛弃新任务的，如果当前线程池状态不是 RUNNING 了则把任务从任务队列移除，移除后执行拒绝策略
				            if (! isRunning(recheck) && remove(command))
				            	// 执行拒绝策略
				                reject(command);
				            // 重新判断当前线程池里面是否还有线程，如果没有则新增一个线程
				            else if (workerCountOf(recheck) == 0)
				                addWorker(null, false);
				        }
				        // 到这里说明任务队列己满，尝试新开启线程来执行该任务，如果当前线程池中线程个数 > maximumPoolSize 则执行拒绝策略
				        else if (!addWorker(command, false))
				            reject(command);
				    }
				二、addWorker(Runnable firstTask, boolean core)：
					addWorker 方法的主要工作是在线程池中创建一个新的线程并执行当前提交的任务，firstTask 参数用于指定当前新增的线程执行的第一个任务。
					core 参数为 true 表示在新增线程时会判断当前活动线程数是否少于 corePoolSize，false 表示新增线程前需要判断当前活动线程数是否少于 maximumPoolSize。
				    private boolean addWorker(Runnable firstTask, boolean core) {
				    	// 第一部分   双重循环的目的是通过 CAS 操作增加线程数
				        retry:
				        for (;;) {
				            int c = ctl.get();
				            // 取当前线程池的运行状态
				            int rs = runStateOf(c);
				            // rs >= SHUTDOWN（判断当前状态是不是SHUTDOWN、STOP、TIDYING、TERMINATED， 不包含RUNNING，因为RUNNING是负数）
				            // 
				            // !(rs == SHUTDOWN &&  firstTask == null && !workQueue.isEmpty()) 相当于：
				            // (rs != SHUTDOWN &&     -----a  • 当前线程池状态为 STOP 、 TIDYING 或 TERMINATED
                    		//   firstTask != null &&    -----b   • 当前线程池状态为 SHUTDOWN 并且己经有了第一个任务
                    		//     workQueue.isEmpty())    -----c    • 当前线程池状态为 SHUTDOWN 并且任务队列为空
                    		// 
				            // 所以该处判断为true的情况包括：a.b.c
				            if (rs >= SHUTDOWN && 
				            	!(rs == SHUTDOWN &&
                   					firstTask == null &&
                   						!workQueue.isEmpty()))
				                return false;
				            // 循环CAS增加线程个数
				            for (;;) {
				                int wc = workerCountOf(c);
				                // 如果线程个数超限则返回 false
				                if (wc >= CAPACITY || wc >= (core ? corePoolSize : maximumPoolSize))
				                    return false;
				                // CAS增加线程个数，同时只有一个线程成功
				                if (compareAndIncrementWorkerCount(c))
				                    break retry;
				                // CAS失败了，则看线程池状态是否变化了，变化则跳到外层循环重新尝试获取线程池状态，否则内层循环重新CAS，否则进入内层循环继续进行 CAS 尝试
				                c = ctl.get();  // Re-read ctl
				                if (runStateOf(c) != rs)
				                    continue retry;
				                // else CAS failed due to workerCount change; retry inner loop
				            }
				        }

				        // 到这里说明 CAS成功了
				        // 第二部分   主要是把并发安全的任务添加到 workers 里面，并且启动任务执行
				        boolean workerStarted = false;
				        boolean workerAdded = false;
				        Worker w = null;
				        try {
				        	// 创建worker
				            w = new Worker(firstTask);
				            final Thread t = w.thread;
				            if (t != null) {
				                final ReentrantLock mainLock = this.mainLock;
				                // 加独占锁，为了实现 workers 同步，因为可能多个线程调用了线程池的execute方法
				                mainLock.lock();
				                try {
				                    // 重新检查线程池状态，这是为了避免在获取锁前其他线程调用了 shutdown 关闭了线程池。
				                    int rs = runStateOf(ctl.get());
				                    if (rs < SHUTDOWN || (rs == SHUTDOWN && firstTask == null)) { // 如果当前线程池状态为 RUNNING 或者 状态为 SHUTDOWN并且当前任务是null
				                        if (t.isAlive()) // 提前检查当前线程（即线开启的线程）是否可启动
				                            throw new IllegalThreadStateException();
				                        // 添加任务
				                        workers.add(w);
				                        int s = workers.size();
				                        if (s > largestPoolSize)
				                            largestPoolSize = s;
				                        workerAdded = true;
				                    }
				                } finally {
				                    mainLock.unlock();
				                }
				                // 添加成功后则启动任务，实际是执行 runWorker 方法。
				                // 为什么？ 这是因为在Worker 的构造函数中 thread 是这样创建的：this.thread = getThreadFactory().newThread(this)，是不是有种恍然大悟的感觉。
				                // 所以一个 Worker 对象在启动的时候会调用 Worker 类中的 run 方法。
				                // 这个点是最终明白线程调度的关键。
				                // 如果你还没有恍然大悟，洗洗睡吧。
				                if (workerAdded) {
				                    t.start();
				                    workerStarted = true;
				                }
				            }
				        } finally {
				            if (! workerStarted)
				                addWorkerFailed(w);
				        }
				        return workerStarted;
				    }
				三、runWorker(Worker w) 执行具体任务的入口
					如果 worker 数量小于
			h.Worker：
				线程池中的每一个线程被封装成一个 Worker 对象，线程池维护的其实就是一组 Worker 对象。
				Worker 继承了 AQS，使用 AQS 来实现独占锁的功能。
				lock 方法一旦获取了独占锁，表示当前线程正在执行任务中；
				如果正在执行任务，则不应该中断线程；
				如果该线程现在不是独占锁的状态，也就是空闲的状态，说明它没有在处理任务，这时可以对该线程进行中断；
				线程池在执行 shutdown 方法或 tryTerminate 方法时会调用 interruptIdleWorkers 方法来中断空闲的线程，interruptIdleWorkers 方法会使用 tryLock 方法来判断线程池中的线程是否是空闲状态；
				之所以设置为不可重入，是因为我们不希望任务在调用像 setCorePoolSize 这样的线程池控制方法时重新获取锁。如果使用 ReentrantLock，它是可重入的，这样如果在任务中调用了如 setCorePoolSize 这类线程池控制的方法，会中断正在运行的线程。
					然而设计可重入锁的目的就是防止死锁的发生，在以下程序中，子类改写了父类的 synchronized 方法，然后调用父类中的方法，此时如果内置锁不是可重入的，那么这段代码将产生死锁。
				由于 Widget 和 LoggingWidget 中 doSomething 方法都是 synchronized 方法，因此每个每个 doSomething 方法在执行前都会获取 Widget 上的锁。然而如果内置锁不是可重入的，那么调用 super.doSomething( )时无法获得 Widget 上的锁，
				因为这个锁已经被持有，从而线程将永远停顿下去，等待一个永远也无法获得的锁。重入则避免了这种死锁情况的发生：	
					public class Widget {
					    public synchronized void doSomething() {
					        ........
					    }
					}

					public class LoggingWidget extends Widget {
					    public synchronized void doSomething() {
					        super.doSomething();
					    }
					}
				此外，在构造方法中执行了 setState(-1);，把 state 变量设置为-1，为什么这么做呢？是因为AQS中默认的 state 是0，如果刚创建了一个 Worker 对象，还没有执行任务时，这时就不应该被中断，看一下 tryAquire 方法：
					protected boolean tryAcquire(int unused) {
					    if (compareAndSetState(0, 1)) {
					        setExclusiveOwnerThread(Thread.currentThread());
					        return true;
					    }
					    return false;
					}
				tryAcquire 方法是根据 state 是否是0来判断的，所以，setState(-1);将 state 设置为-1是为了禁止在执行任务前对线程进行中断。
				正因为如此，在 runWorker 方法中会先调用 Worker 对象的 unlock 方法将 state 设置为0。


	4、submit 和 execut 方法的区别、线程的调度过程
		submit 方法在接口 ExecutorService 中定义，而 executor 在 Executor 中定义。
		execute(Runnable x) 没有返回值。可以执行任务，但无法判断任务是否成功完成。（异步执行）
		submit(Runnable task) 返回一个 Future。通过 get 等待直到获取到检索结果为止。（同步执行）
		而且 submit 内部调用了execute 方法。
		Future：
			public interface Future<V> {
			    boolean cancel(boolean mayInterruptIfRunning);
			    boolean isCancelled();
			    boolean isDone();
			    V get() throws InterruptedException, ExecutionException;
			    V get(long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;
			}
		submit 内部使用 FutureTask 这个实现类来新建一个 Future 对象并返回给用户，用户可以用这个 Future 来异步获取线程最终的执行结果。
		Future 表示异步计算的结果。它提供了检查计算是否完成的方法，以等待计算的完成，并获取计算的结果。计算完成后只能使用 get 方法来获取结果，如果线程没有执行完，Future.get()方法可能会阻塞当前线程的执行；如果线程出现异常，
		Future.get() 会 throws InterruptedException 或者 ExecutionException；如果线程已经取消，会跑出 CancellationException。取消由 cancel 方法来执行。isDone 确定任务是正常完成还是被取消了。一旦计算完成，就不能再取消计算。

	5、线程池如何调优
	6、线程池的最大线程数目根据什么确定
	7、动态代理的几种方式
		JDK 静态代理
			HelloInterface ——> sayHello();
			Hello ——> sayHello() {sout("Hello Eureka");}
			public class HelloProxy implements HelloInterface {
			    private HelloInterface hello = new Hello();
			    @Override
			    public sayHello() {sout("PRE PRE"); hello.sayHello(); sout("POST POST");}
			}
		JDK 动态代理
			HelloInterface ——> sayHello();
			Hello ——> sayHello() {sout("Hello Eureka");}
			public class HelloProxy implements InvocationHandler {
			    private Object object;
			    public HelloProxy (Object object) { this.object = object; }
			    @Override
			    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
			        System.out.println("PRE PRE"); method.invoke(object, args); System.out.println("POST POST"); return null;
			    }
			}
			public class ProxyClient {
			    public static void main(String[] args) {
			        Hello hello = new Hello();
			        InvocationHandler handler = new HelloProxy(hello);
			        // 1
			        HelloInterface proxy = (HelloInterface) Proxy.newProxyInstance(handler.getClass().getClassLoader(), hello.getClass().getInterfaces(), handler);
			        // 2
			        proxy.sayHello();
			    }
			}
			关键点： 上边的 HelloInterface proxy 这个代理类(代码片段1)，其实就是通过动态代理生成的 HelloInterface 接口的实现类，该实现类继承了 Proxy 这个类，核心代码如下（通过反编译生成的，实际代码还是比较多的）：
				//继承了Proxy类
				public final class $Proxy extends Proxy implements HelloInterface {
				    public $Proxy(InvocationHandler var1) throws  {
				        super(var1);
				    }
				    public final void sayHello() throws  {
				        try {
				            super.h.invoke(this, m3, (Object[])null);
				        } catch (RuntimeException | Error var2) {
				            throw var2;
				        } catch (Throwable var3) {
				            throw new UndeclaredThrowableException(var3);
				        }
				    }
				}
				代码片段2执行会调用这个动态生成的代理实现类的 sayHello 方法。

			总结：
				类加载器是干嘛的：其
					一：JDK内部需要通过类加载作为缓存的key 
					二：需要类加载器生成class
				为什么需要接口：
					生成的代理类继承了Proxy，由于java是单继承，所以只能实现接口，通过接口实现，充分利用了java的多态特性，也符合基于接口编码的规范
				为什么 JDK 动态代理只能代理接口：
					因为生成的代理类已经继承了 Proxy 类，Java 是单继承的，所以没法再继承另外一个类了。
				有一些博客上可能会说 cglib 和 JDK 动态代理的区别，cglib 是通过操作字节码去完成代理的，其实JDK动态代理也操作了字节码。
		JDK 静态代理与 JDK 动态代理比较：
			相同点：
				都要创建代理类，以及代理类都要实现接口等。
			不同点：
				在静态代理中我们需要对哪个接口和哪个被代理类创建代理类，所以我们在编译前就需要代理类实现与被代理类相同的接口，并且直接在实现的方法中调用被代理类相应的方法；
				但是动态代理则不同，我们不知道要针对哪个接口、哪个被代理类创建代理类，因为它是在运行时被创建的。
				JDK静态代理是通过直接编码创建的，JDK动态代理是利用反射机制在运行时创建代理类的。
		JDK 动态代理类生成是通过 Proxy 类中的 newProxyInstance 来完成的：
			public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException {
			    //如果h为空将抛出异常
			    Objects.requireNonNull(h);
			    final Class<?>[] intfs = interfaces.clone();//拷贝被代理类实现的一些接口，用于后面权限方面的一些检查
			    final SecurityManager sm = System.getSecurityManager();
			    if (sm != null) {
			        //在这里对某些安全权限进行检查，确保我们有权限对预期的被代理类进行代理
			        checkProxyAccess(Reflection.getCallerClass(), loader, intfs);
			    }
			    /*
			     * 下面这个方法将产生代理类
			     */
			    Class<?> cl = getProxyClass0(loader, intfs);
			    /*
			     * 使用指定的调用处理程序获取代理类的构造函数对象
			     */
			    try {
			        if (sm != null) {
			            checkNewProxyPermission(Reflection.getCallerClass(), cl);
			        }
			        final Constructor<?> cons = cl.getConstructor(constructorParams);
			        final InvocationHandler ih = h;
			        //假如代理类的构造函数是private的，就使用反射来set accessible
			        if (!Modifier.isPublic(cl.getModifiers())) {
			            AccessController.doPrivileged(new PrivilegedAction<Void>() {
			                public Void run() {
			                    cons.setAccessible(true);
			                    return null;
			                }
			            });
			        }
			        //根据代理类的构造函数来生成代理类的对象并返回
			        return cons.newInstance(new Object[]{h});
			    } catch (IllegalAccessException|InstantiationException e) {
			        throw new InternalError(e.toString(), e);
			    } catch (InvocationTargetException e) {
			        Throwable t = e.getCause();
			        if (t instanceof RuntimeException) {
			            throw (RuntimeException) t;
			        } else {
			            throw new InternalError(t.toString(), t);
			        }
			    } catch (NoSuchMethodException e) {
			        throw new InternalError(e.toString(), e);
			    }
			}

			/**
		     * 生成一个代理类，但是在调用本方法之前必须进行权限检查
		     */
		    private static Class<?> getProxyClass0(ClassLoader loader, Class<?>... interfaces) {
		        //如果接口数量大于65535，抛出非法参数错误
		        if (interfaces.length > 65535) { throw new IllegalArgumentException("interface limit exceeded"); }
		        // 如果在缓存中有对应的代理类，那么直接返回 否则代理类将有 ProxyClassFactory 来创建
		        return proxyClassCache.get(loader, interfaces);
		    }

		    public V get(K key, P parameter) {
		        Objects.requireNonNull(parameter);

		        expungeStaleEntries();
		        //通过上游方法，可以知道key是类加载器，这里是通过类加载器可以获得第一层key
		       Object cacheKey = CacheKey.valueOf(key, refQueue);
		        
		       //我们查看map的定义，可以看到map变量是一个两层的ConcurrentMap
		       ConcurrentMap<Object, Supplier<V>> valuesMap = map.get(cacheKey);//通过第一层key尝试获取数据
		       //如果valuesMap 为空，就新建一个ConcurrentHashMap，
		       //key就是生成出来的cacheKey，并把这个新建的ConcurrentHashMap推到map
		       if (valuesMap == null) {
		            ConcurrentMap<Object, Supplier<V>> oldValuesMap
		                = map.putIfAbsent(cacheKey,
		                                  valuesMap = new ConcurrentHashMap<>());
		            if (oldValuesMap != null) {
		                valuesMap = oldValuesMap;
		            }
		        }

		        //通过上游方法可以知道key是类加载器，parameter是类本身，这里是通过类加载器和类本身获得第二层key
		        Object subKey = Objects.requireNonNull(subKeyFactory.apply(key, parameter));
		        Supplier<V> supplier = valuesMap.get(subKey);
		        Factory factory = null;

		        while (true) {
		            if (supplier != null) {
		                //如果有缓存，直接调用get方法后返回，当没有缓存，会继续执行后面的代码，
		                //由于while (true)，会第二次跑到这里，再get返回出去，
		                //其中get方法调用的是WeakCahce中的静态内部类Factory的get方法
		                V value = supplier.get();
		                if (value != null) {
		                    return value;
		                }
		            }
		            //当factory为空，会创建Factory对象
		            if (factory == null) {
		                factory = new Factory(key, parameter, subKey, valuesMap);
		            }

		            if (supplier == null) {
		                supplier = valuesMap.putIfAbsent(subKey, factory);
		                if (supplier == null) {
		                    //当没有代理类缓存的时候，会运行到这里，把Factory的对象赋值给supplier ，
		                    //进行下一次循环，supplier就不为空了，可以调用get方法返回出去了，
		                    //这个Factory位于WeakCahce类中，是一个静态内部类
		                    supplier = factory;
		                }
		            } else {
		                if (valuesMap.replace(subKey, supplier, factory)) {
		                    supplier = factory;
		                } else {
		                    supplier = valuesMap.get(subKey);
		                }
		            }
		        }
		    }

	        /**
		     *  里面有一个根据给定ClassLoader和Interface来创建代理类的工厂函数  
		     *
		     */
		    private static final class ProxyClassFactory implements BiFunction<ClassLoader, Class<?>[], Class<?>> {
		        // 代理类的名字的前缀统一为“$Proxy”
		        private static final String proxyClassNamePrefix = "$Proxy";

		        // 每个代理类前缀后面都会跟着一个唯一的编号，如$Proxy0、$Proxy1、$Proxy2
		        private static final AtomicLong nextUniqueNumber = new AtomicLong();

		        @Override
		        public Class<?> apply(ClassLoader loader, Class<?>[] interfaces) {
		            Map<Class<?>, Boolean> interfaceSet = new IdentityHashMap<>(interfaces.length);
		            for (Class<?> intf : interfaces) {
		                /*
		                 * 验证类加载器加载接口得到对象是否与由apply函数参数传入的对象相同
		                 */
		                Class<?> interfaceClass = null;
		                try {
		                    interfaceClass = Class.forName(intf.getName(), false, loader);
		                } catch (ClassNotFoundException e) {
		                }
		                if (interfaceClass != intf) {
		                    throw new IllegalArgumentException(intf + " is not visible from class loader");
		                }
		                /*
		                 * 验证这个Class对象是不是接口
		                 */
		                if (!interfaceClass.isInterface()) {
		                    throw new IllegalArgumentException(
		                        interfaceClass.getName() + " is not an interface");
		                }
		                /*
		                 * 验证这个接口是否重复
		                 */
		                if (interfaceSet.put(interfaceClass, Boolean.TRUE) != null) {
		                    throw new IllegalArgumentException("repeated interface: " + interfaceClass.getName());
		                }
		            }
		            String proxyPkg = null;     // 声明代理类所在的package
		            int accessFlags = Modifier.PUBLIC | Modifier.FINAL;
		            /*
		             * 记录一个非公共代理接口的包，以便在同一个包中定义代理类。同时验证所有非公共
		             * 代理接口都在同一个包中
		             */
		            for (Class<?> intf : interfaces) {
		                int flags = intf.getModifiers();
		                if (!Modifier.isPublic(flags)) {
		                    accessFlags = Modifier.FINAL;
		                    String name = intf.getName();
		                    int n = name.lastIndexOf('.');
		                    String pkg = ((n == -1) ? "" : name.substring(0, n + 1));
		                    if (proxyPkg == null) {
		                        proxyPkg = pkg;
		                    } else if (!pkg.equals(proxyPkg)) {
		                        throw new IllegalArgumentException("non-public interfaces from different packages");
		                    }
		                }
		            }
		            if (proxyPkg == null) {
		                // 如果全是公共代理接口，那么生成的代理类就在com.sun.proxy package下
		                proxyPkg = ReflectUtil.PROXY_PACKAGE + ".";
		            }
		            /*
		             * 为代理类生成一个name  package name + 前缀+唯一编号
		             * 如 com.sun.proxy.$Proxy0.class
		             */
		            long num = nextUniqueNumber.getAndIncrement();
		            String proxyName = proxyPkg + proxyClassNamePrefix + num;
		            /*
		             * 生成指定代理类的字节码文件
		             */
		            byte[] proxyClassFile = ProxyGenerator.generateProxyClass(proxyName, interfaces, accessFlags);
		            try {
		                return defineClass0(loader, proxyName, proxyClassFile, 0, proxyClassFile.length);
		            } catch (ClassFormatError e) {
		                throw new IllegalArgumentException(e.toString());
		            }
		        }
		    }

		    private byte[] generateClassFile() {
		        //下面一系列的addProxyMethod方法是将接口中的方法和Object中的方法添加到代理方法中(proxyMethod)
		        this.addProxyMethod(hashCodeMethod, Object.class);
		        this.addProxyMethod(equalsMethod, Object.class);
		        this.addProxyMethod(toStringMethod, Object.class);
		        Class[] var1 = this.interfaces;
		        int var2 = var1.length;

		        int var3;
		        Class var4;
		       //获得接口中所有方法并添加到代理方法中
		        for(var3 = 0; var3 < var2; ++var3) {
		            var4 = var1[var3];
		            Method[] var5 = var4.getMethods();
		            int var6 = var5.length;

		            for(int var7 = 0; var7 < var6; ++var7) {
		                Method var8 = var5[var7];
		                this.addProxyMethod(var8, var4);
		            }
		        }

		        Iterator var11 = this.proxyMethods.values().iterator();
		        //验证具有相同方法签名的方法的返回类型是否一致
		        List var12;
		        while(var11.hasNext()) {
		            var12 = (List)var11.next();
		            checkReturnTypes(var12);
		        }

		        //后面一系列的步骤用于写代理类Class文件
		        Iterator var15;
		        try {
		             //生成代理类的构造函数
		            this.methods.add(this.generateConstructor());
		            var11 = this.proxyMethods.values().iterator();

		            while(var11.hasNext()) {
		                var12 = (List)var11.next();
		                var15 = var12.iterator();

		                while(var15.hasNext()) {
		                    ProxyGenerator.ProxyMethod var16 = (ProxyGenerator.ProxyMethod)var15.next();
		                    //将代理类字段声明为Method，并且字段修饰符为 private static.
		                   //因为 10 是 ACC_PRIVATE和ACC_STATIC的与运算 故代理类的字段都是 private static Method ***
		                    this.fields.add(new ProxyGenerator.FieldInfo(var16.methodFieldName, 
		                                   "Ljava/lang/reflect/Method;", 10));
		                   //生成代理类的方法
		                    this.methods.add(var16.generateMethod());
		                }
		            }
		           //为代理类生成静态代码块对某些字段进行初始化
		            this.methods.add(this.generateStaticInitializer());
		        } catch (IOException var10) {
		            throw new InternalError("unexpected I/O Exception", var10);
		        }

		        if(this.methods.size() > '\uffff') { //代理类中的方法数量超过65535就抛异常
		            throw new IllegalArgumentException("method limit exceeded");
		        } else if(this.fields.size() > '\uffff') {// 代理类中字段数量超过65535也抛异常
		            throw new IllegalArgumentException("field limit exceeded");
		        } else {
		            // 后面是对文件进行处理的过程
		            this.cp.getClass(dotToSlash(this.className));
		            this.cp.getClass("java/lang/reflect/Proxy");
		            var1 = this.interfaces;
		            var2 = var1.length;

		            for(var3 = 0; var3 < var2; ++var3) {
		                var4 = var1[var3];
		                this.cp.getClass(dotToSlash(var4.getName()));
		            }

		            this.cp.setReadOnly();
		            ByteArrayOutputStream var13 = new ByteArrayOutputStream();
		            DataOutputStream var14 = new DataOutputStream(var13);

		            try {
		                var14.writeInt(-889275714);
		                var14.writeShort(0);
		                var14.writeShort(49);
		                this.cp.write(var14);
		                var14.writeShort(this.accessFlags);
		                var14.writeShort(this.cp.getClass(dotToSlash(this.className)));
		                var14.writeShort(this.cp.getClass("java/lang/reflect/Proxy"));
		                var14.writeShort(this.interfaces.length);
		                Class[] var17 = this.interfaces;
		                int var18 = var17.length;

		                for(int var19 = 0; var19 < var18; ++var19) {
		                    Class var22 = var17[var19];
		                    var14.writeShort(this.cp.getClass(dotToSlash(var22.getName())));
		                }

		                var14.writeShort(this.fields.size());
		                var15 = this.fields.iterator();

		                while(var15.hasNext()) {
		                    ProxyGenerator.FieldInfo var20 = (ProxyGenerator.FieldInfo)var15.next();
		                    var20.write(var14);
		                }

		                var14.writeShort(this.methods.size());
		                var15 = this.methods.iterator();

		                while(var15.hasNext()) {
		                    ProxyGenerator.MethodInfo var21 = (ProxyGenerator.MethodInfo)var15.next();
		                    var21.write(var14);
		                }

		                var14.writeShort(0);
		                return var13.toByteArray();
		            } catch (IOException var9) {
		                throw new InternalError("unexpected I/O Exception", var9);
		            }
		        }
		    }

		    private void addProxyMethod(Method var1, Class<?> var2) {
		        String var3 = var1.getName();//获得方法名称
		        Class[] var4 = var1.getParameterTypes();//获得方法参数类型
		        Class var5 = var1.getReturnType();//获得方法返回类型
		        Class[] var6 = var1.getExceptionTypes();//异常类型
		        String var7 = var3 + getParameterDescriptors(var4);//获得方法签名
		        Object var8 = (List)this.proxyMethods.get(var7);//根据方法前面获得proxyMethod的value
		        if(var8 != null) {//处理多个代理接口中方法重复的情况
		            Iterator var9 = ((List)var8).iterator();

		            while(var9.hasNext()) {
		                ProxyGenerator.ProxyMethod var10 = (ProxyGenerator.ProxyMethod)var9.next();
		                if(var5 == var10.returnType) {
		                    ArrayList var11 = new ArrayList();
		                    collectCompatibleTypes(var6, var10.exceptionTypes, var11);
		                    collectCompatibleTypes(var10.exceptionTypes, var6, var11);
		                    var10.exceptionTypes = new Class[var11.size()];
		                    var10.exceptionTypes = (Class[])var11.toArray(var10.exceptionTypes);
		                    return;
		                }
		            }
		        } else {
		            var8 = new ArrayList(3);
		            this.proxyMethods.put(var7, var8);
		        }
		        ((List)var8).add(new ProxyGenerator.ProxyMethod(var3, var4, var5, var6, var2, null));
		    }
		======================================================================================================================
		==================== CGLIB 原理剖析：基于ASM的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成 ====================
		======================================================================================================================
		在实现内部，CGLIB库使用了ASM这一个轻量但高性能的字节码操作框架来转化字节码，产生新类。
		值得说的是，它比JDK动态代理还要快。

		public class HelloConcrete {
		    public String sayHello(String str) {
		        return "HelloConcrete: " + str;
		    }
		}
		public class MyMethodInterceptor implements MethodInterceptor {
		    public static Object getProxy(Class targetClass) {
		        Enhancer enhancer = new Enhancer();
		        enhancer.setSuperclass(targetClass);
		        enhancer.setCallback(new MyMethodInterceptor());
		        return enhancer.create();
		    }
		    @Override
		    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
		        System.out.println("You said: " + Arrays.toString(args));
		        return proxy.invokeSuper(obj, args);
		    }
		}
		public static void main(String[] args) {
	        HelloConcrete proxy = (HelloConcrete) MyMethodInterceptor.getProxy(HelloConcrete.class);
	        System.out.println(proxy.sayHello("I love you!"));
	    }
	    总结：
	    	上述代码中，我们通过 CGLIB 的 Enhancer 来指定要代理的目标对象、实际处理代理逻辑的对象，最终通过调用 create() 方法得到代理对象，对这个对象所有非 final 方法的调用
			都会转发给 MethodInterceptor.intercept()方法，在 intercept()方法里我们可以加入任何逻辑，比如修改方法参数，加入日志功能、安全检查功能等；通过调用 MethodProxy.invokeSuper() 方法，
			我们将调用转发给原始对象，具体到本例，就是 HelloConcrete 的具体方法。CGLIG 中 MethodInterceptor 的作用跟 JDK 代理中的 InvocationHandler 很类似，都是方法调用的中转站。
			# HelloConcrete代理对象的类型信息
			class=class cglib.HelloConcrete$$EnhancerByCGLIB$$e3734e52
			superClass=class lh.HelloConcrete
			interfaces: 
			interface net.sf.cglib.proxy.Factory
			invocationHandler=not java proxy class
			CGLIB 代理之后的对象类型是 cglib.HelloConcrete$$EnhancerByCGLIB$$e3734e52，这是 CGLIB 动态生成的类型；父类是 HelloConcrete，
			印证了 CGLIB 是通过继承实现代理；同时实现了 net.sf.cglib.proxy.Factory 接口，这个接口是 CGLIB 自己加入的，包含一些工具方法。
			对于从 Object 中继承的方法，CGLIB 代理也会进行代理，如 hashCode()、equals()、toString()等，但是 getClass()、wait()等方法不会，因为它是 final 方法，CGLIB 无法代理。
			既然是继承就不得不考虑 final 的问题。我们知道 final 类型不能有子类，所以CGLIB不能代理 final 类型。同样，只能代理非 final 修饰的非抽象类的非 final 方法。
			cglib.HelloConcrete$$EnhancerByCGLIB$$e3734e52 具体内容是：
			CGLIB代理类具体实现如下：
			public class HelloConcrete$$EnhancerByCGLIB$$e3734e52 extends HelloConcrete implements Factory {
			  ...
			  private MethodInterceptor CGLIB$CALLBACK_0; // ~~
			  ...
			  public final String sayHello(String paramString) {
			    ...
			    MethodInterceptor tmp17_14 = CGLIB$CALLBACK_0;
			    if (tmp17_14 != null) {
			      // 将请求转发给MethodInterceptor.intercept()方法。
			      return (String)tmp17_14.intercept(this, 
			              CGLIB$sayHello$0$Method, 
			              new Object[] { paramString }, 
			              CGLIB$sayHello$0$Proxy);
			    }
			    return super.sayHello(paramString);
			  }
			  ...
			}

	8、HashMap 的并发问题
		一、多线程的 put 可能导致元素的丢失：
			final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
			    Node<K,V>[] tab; Node<K,V> p; int n, I;
			    // 初始化hash表
			    if ((tab = table) == null || (n = tab.length) == 0)
			        n = (tab = resize()).length;
			    // 通过hash值计算在hash表中的位置，并将这个位置上的元素赋值给p，如果是空的则new一个新的node放在这个位置上
			    if ((p = tab[i = (n - 1) & hash]) == null)
			        tab[i] = newNode(hash, key, value, null);
			    else {
			        // hash表的当前index已经存在元素，向这个元素后追加链表
			        Node<K,V> e; K k;
			        if (p.hash == hash &&
			            ((k = p.key) == key || (key != null && key.equals(k))))
			            e = p;
			        else if (p instanceof TreeNode)
			            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
			        else {
			            for (int binCount = 0; ; ++binCount) {
			                // 新建节点并追加到链表
			                if ((e = p.next) == null) { // #1
			                    p.next = newNode(hash, key, value, null); // #2
			                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
			                        treeifyBin(tab, hash);
			                    break;
			                }
				......
				......
			}
			Thread1 和 Thread2 同时执行 put 操作，且两个 key 的 hashcode 相同且对应的在数组下标处已有数据（即链表上有1个或多个数据的时候），正常情况下把这两个线程的操作的 key 依次追加到该链表末尾，
			但由于是并发执行，且同时执行了 #1 处代码片段，即 (e = p.next) == null 判断都为 true，然后 Thread1 先执行了 #2，接着 Thread2 执行了 #2。结果就是 Thread2 覆盖了 Thread1 的元素。
		二、put 和 get 并发时，可能导致 get 为 null：
			场景：线程1执行put时，因为元素个数超出threshold而导致rehash，线程2此时执行get，有可能导致这个问题。
			// hash表
			transient Node<K,V>[] table;
			......
			final Node<K,V>[] resize() {
				// 计算新hash表容量大小，begin
				......
				......
				// 计算新hash表容量大小，end
				//@SuppressWarnings({"rawtypes","unchecked”})
				Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap]; // #1
			    table = newTab; // #2
			    // rehash begin
			    if (oldTab != null) {
			        for (int j = 0; j < oldCap; ++j) {
			    ......
				......
			}
			在代码 #1 位置，用新计算的容量 new 了一个新的 hash 表，#2 将新创建的空 hash 表赋值给实例变量 table。注意此时实例变量table是空的。那么，如果此时另一个线程执行get时，就会get出null。
		三、size 值会不准确：
			transient int size;（不参与序列化）在各个线程中的size副本不会及时同步，在多个线程操作的时候，size将会被覆盖。
	8.1、SortedMap：

	8.2、HashSet：

	8.3、LinkedHashSet: 
		https://blog.csdn.net/zhaojie181711/article/details/80510129
	9、了解 LinkedHashMap 的应用吗？
		重点在于：插入有序和访问有序。
		LinkedHashMap 拥有与 HashMap 相同的底层哈希表结构，即数组 + 单链表 + 红黑树，也拥有相同的扩容机制。
		LinkedHashMap 相比 HashMap 的拉链式存储结构，内部额外通过 Entry （extends HashMap.Node<K,V>） 维护了一个双向链表。
		HashMap 元素的遍历顺序不一定与元素的插入顺序相同，而 LinkedHashMap 则通过遍历双向链表来获取元素，所以遍历顺序在一定条件下等于插入顺序。
		LinkedHashMap 可以通过构造参数 accessOrder 来指定双向链表是否在元素被访问后改变其在双向链表中的位置。
		首先分析 put 函数，并没有重写 hashmap 的 put 函数：
			final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
			    Node<K,V>[] tab; Node<K,V> p; int n, i;
			    // table为空，则通过扩容来创建，后面在看扩容函数
			    if ((tab = table) == null || (n = tab.length) == 0)
			        n = (tab = resize()).length;
			    // 根据key的hash值 与 数组长度进行取模来得到数组索引    
			    if ((p = tab[i = (n - 1) & hash]) == null)
			        // 空链表，创建节点
			        tab[i] = newNode(hash, key, value, null);
			    else {
			        Node<K,V> e; K k;
			        // 不为空，则判断是否与当前节点一样，一样就进行覆盖
			        if (p.hash == hash &&
			            ((k = p.key) == key || (key != null && key.equals(k))))
			            e = p;
			        else if (p instanceof TreeNode)
			            // 不存在重复节点，则判断是否属于树节点，如果属于树节点，则通过树的特性去添加节点
			            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
			        else {
			            // 该链为链表
			            for (int binCount = 0; ; ++binCount) {
			                // 当链表遍历到尾节点时，则插入到最后 -> 尾插法
			                if ((e = p.next) == null) {
			                	========== 重写 1 ==========
			                    p.next = newNode(hash, key, value, null);
			                    // 检测是否该从链表变成树（注意：这里是先插入节点，没有增加binCount,所以判断条件是大于等于阈值-1）
			                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
			                        // 满足则树形化
			                        treeifyBin(tab, hash);
			                    break;
			                }
			                if (e.hash == hash &&
			                    ((k = e.key) == key || (key != null && key.equals(k))))
			                    break;
			                p = e;
			            }
			        }
			        
			        // 存在相同的key, 则替换value
			        if (e != null) { // existing mapping for key
			            V oldValue = e.value;
			            if (!onlyIfAbsent || oldValue == null)
			                e.value = value；
			            ========== 重写 2 ==========
			            // 注意这里，这里是供子类LinkedHashMap实现    
			            afterNodeAccess(e);
			            return oldValue;
			        }
			    }
			    ++modCount;
			    // 注意细节：先加入节点，再加长度与阈值进行判断，是否需要扩容。
			    if (++size > threshold)
			        resize();
			    ========== 重写 3 ==========
			    // 注意这里，这里是供子类LinkedHashMap实现        
			    afterNodeInsertion(evict);
			    return null;
			}
			重写 1：
				每次插入都会调用newNode函数创建一个新节点，对于LinkeHashMap来说有重写该函数。
				Node<K,V> newNode(int hash, K key, V value, Node<K,V> e) {
				    // 调用父类创建节点， 没什么区别。
				    LinkedHashMap.Entry<K,V> p =
				        new LinkedHashMap.Entry<K,V>(hash, key, value, e);
				    // 新加的方法    
				    linkNodeLast(p);
				    return p;
				}
				private void linkNodeLast(LinkedHashMap.Entry<K,V> p) {
				    LinkedHashMap.Entry<K,V> last = tail;
				    tail = p;
				    // 如果双向链表为空，则当前节点是第一个节点
				    if (last == null)
				        head = p;
				    else {
				        // 将新创建的节点添加至双向链表的尾部。
				        p.before = last;
				        last.after = p;
				    }
				}
			重写 2：
				当存在相同 key 替换 value 后，会调用 afterNodeAccess 函数，这函数在 HashMap 中是没有任何实现的，主要是供子类 LinkeHashMap 来实现。
				当访问到双向链表存在的值时，如果开启访问有序的开关，则会将访问到的节点移至到双向链表的尾部。见下边代码片段分析：
				void afterNodeAccess(Node<K,V> e) { // move node to last
				    LinkedHashMap.Entry<K,V> last;
				    // 如果accessOrder=true,即访问有序，且双向链表不止一个节点的时候，进行下面操作：
				    if (accessOrder && (last = tail) != e) {
				        LinkedHashMap.Entry<K,V> p =
				            (LinkedHashMap.Entry<K,V>)e, b = p.before, a = p.after;
				        // 将p的后置指针置为null     
				        p.after = null; 
				        // 如果e的前置指针没有元素, 则直接将双向链表的头节点指向它。
				        if (b == null)
				            head = a;
				        else
				            // e的前置指针存在元素, 则将e的前置指针指向节点的后置指针指向其后置指针指向的的节点。
				            b.after = a;
				        // e的后置指针存在元素, 则将e的后置指针指向节点的前置指针指向e前置指针指向的节点    
				        if (a != null)
				            a.before = b;
				        else
				            // 否则将尾节点指向e的前置节点
				            last = b;
				        // 上面步骤主要是将e节点从链表中移除，然后添加到链表尾部    
				        if (last == null)
				            head = p;
				        else {
				            // 添加置链表尾部
				            p.before = last;
				            last.after = p;
				        }
				        tail = p;
				        ++modCount;
				    }
				}
				另外get函数也会调用这个函数，所以从源码的角度去看问题很清晰：
				public V get(Object key) {
				    Node<K,V> e;
				    if ((e = getNode(hash(key), key)) == null)
				        return null;
				    // 如果存在节点且开启了访问有序的开关，则会将当前节点移至双向链表尾部    
				    if (accessOrder)
				        afterNodeAccess(e);
				    return e.value;
				}
			重写 3：
				当扩容完后，会调用 afterNodeInsertion 函数，同理这个函数也是供子类 LinkeHashMap 来实现的。
				该函数表示是否需要删除最年长的节点：
				void afterNodeInsertion(boolean evict) { // possibly remove eldest
				    LinkedHashMap.Entry<K,V> first；
				    if (evict && (first = head) != null && removeEldestEntry(first)) {
				        // 获取头节点：头节点表示最近很久没有访问的元素
				        K key = first.key;
				        removeNode(hash(key), key, null, false, true);
				    }
				}
				// 返回false, 所以LinkedHashMap不会有删除年长节点的行为，但其子类可以继承重写该函数。
				protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
				    return false;
				}
			forEach：
				public void forEach(BiConsumer<? super K, ? super V> action) {
			        if (action == null)
			            throw new NullPointerException();
			        int mc = modCount;
			        // 遍历的是双向链表。所以我们看到的就是插入的顺序
			        for (LinkedHashMap.Entry<K,V> e = head; e != null; e = e.after)
			            action.accept(e.key, e.value);
			        if (modCount != mc)
			            throw new ConcurrentModificationException();
			    }
	9.1、HashMap的loadFactor为什么是0.75？
		如果是0.5 ， 那么每次达到容量的一半就进行扩容，默认容量是16， 达到8就扩容成32，达到16就扩容成64， 最终使用空间和未使用空间的差值会逐渐增加，空间利用率低下。  
		如果是1，那意味着每次空间使用完毕才扩容，在一定程度上会增加put时候的时间。
		默认负载因子（0.75）在时间和空间成本上提供了很好的折衷，较高的值会降低空间开销，但提高查找成本。
	10、反射的原理，反射创建类实例的三种方式是什么？
		就是指程序在运行时能够动态的获取到一个类的类型信息的一种操作。它是现代框架的灵魂，几尽所有的框架能够提供的一些自动化机制都是靠反射实现的，这也是为什么各类框架都不允许你覆盖掉默认的无参构造器的原因，
		因为框架需要以反射机制利用无参构造器创建实例。
		一、Class 类型信息：
			虚拟机的类加载机制中，每一种类型都会在初次使用时被加载进虚拟机内存的方法区中，包含类中定义的属性字段，方法字节码等信息。
			Java 中使用类 java.lang.Class 来指向一个类型信息，通过这个 Class 对象，我们就可以得到该类的所有内部信息。
			而获取一个 Class 对象的方法主要有以下三种（通过这些方法你可以得到任意类的类型信息，该类的所有字段属性，方法表等信息都可以通过这个 Class 对象进行获取）： 
				类名.class：
					只要使用类名点 class 即可得到方法区该类型的类型信息
				getClass：
					Object 类 方法 public final native Class<?> getClass();
					new ObjectOne().getClass();
				forName（Class 类的静态方法）:
					允许你传入一个全类名，该方法会返回方法区代表这个类型的 Class 对象，如果这个类还没有被加载进方法区，forName 会先进行类加载。
					由于方法区 Class 类型信息由类加载器和类全限定名唯一确定，所以想要去找这么一个 Class 就必须提供类加载器和类全限定名，这个 forName 方法默认使用调用者的类加载器。
					public static Class<?> forName(String className) {
						// native 方法
					    Class<?> caller = Reflection.getCallerClass();
					    // native 方法
					    return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
					}
					Class 类中也有一个 forName 重载，允许你传入类加载器和类全限定名来匹配方法区类型信息：
					public static Class<?> forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException {
				        Class<?> caller = null;
				        SecurityManager sm = System.getSecurityManager();
				        if (sm != null) {
				            caller = Reflection.getCallerClass();
				            if (sun.misc.VM.isSystemDomainLoader(loader)) {
				                ClassLoader ccl = ClassLoader.getClassLoader(caller);
				                if (!sun.misc.VM.isSystemDomainLoader(ccl)) {
				                    sm.checkPermission(
				                        SecurityConstants.GET_CLASSLOADER_PERMISSION);
				                }
				            }
				        }
				        return forName0(name, initialize, loader, caller);
				    }
		二、反射字段属性
			一个 Field 实例包含某个类的一个属性的所有信息，包括字段名称，访问修饰符，字段类型。除此之外，Field 还提供了大量的操作该属性值的方法。
			Class 中有关获取字段属性的方法主要以下几个：
				public Field[] getFields()：返回该类型的所有 public 修饰的属性，包括父类的
				public Field getField(String name)：根据字段名称返回相应的字段
				public Field[] getDeclaredFields()：返回本类型中申明的所有字段，包含非 public 修饰的但不包含父类中的
				public Field getDeclaredField(String name)：同理
			通过传入一个类实例，就可以直接使用 Field 实例操作该实例的当前字段属性的值：
				public class ReflectClient {
				    public static void main(String[] args) throws Exception {
				        Class<People> cls = People.class;
				        Field name = cls.getField("name");
				        People people = new People();
				        // 检索 People 对象是否具有一个 name 代表的字段，如果有将字符串 hello 赋值给该字段即可
				        name.set(people,"hello");
				        // console: hello
				        System.out.println(people.name);
				    }
				    public static class People {
				        public String name;
				    }
				}
		三、反射方法：
			Method 抽象地代表了一个方法，同样有描述这个方法基本信息的字段和方法，例如方法名，方法的参数集合，方法的返回值类型，异常类型集合，方法的注解等。
			Class 类也提供了四种方法来获取其中的方法属性：
				public Method[] getMethods()：返回所有的 public 方法，包括父类中的
				public Method getMethod(String name, Class<?>... parameterTypes)：返回指定的方法
				public Method[] getDeclaredMethods()：返回本类申明的所有方法，包括非 public 修饰的，但不包括父类中的
				public Method getDeclaredMethod(String name, Class<?>... parameterTypes)：同理
			invoke 方法用于间接调用其他实例的该方法：
				public class ReflectClient {
				    public static void main(String[] args) throws Exception {
				        Class<People> cls = People.class;
				        Method sayHello = cls.getMethod("sayHello");
				        People people = new People();
				        // console：hello wrold
				        sayHello.invoke(people);
				    }
				    public static class People {
				        public void sayHello() {
				            System.out.println("hello wrold ");
				        }
				    }
				}
		四、反射构造器：
			Class 类依然为它提供了四种获取实例的方法：
				public Constructor<?>[] getConstructors()：返回所有 public 修饰的构造器
				public Constructor getConstructor(Class<?>... parameterTypes)：带指定参数的
				public Constructor<?>[] getDeclaredConstructors()：返回所有的构造器，无视访问修饰符
				public Constructor getDeclaredConstructor(Class<?>... parameterTypes) ：同理
			Constructor 类中有一个 newInstance 方法用于创建一个该 Class 类型的实例对象出来：
				public class ReflectClient {
				    public static void main(String[] args) throws Exception {
				        Class<People> cls = People.class;
				        Constructor c = cls.getConstructor();
				        People p = (People) c.newInstance();
				        // console：hello wrold
				        p.sayHello();
				    }
				    public static class People {
				        public void sayHello() {
				            System.out.println("hello wrold ");
				        }
				    }
				}
		五、反射与数组：
			数组是一种特殊的类型，它本质上由虚拟机在运行时动态生成，所以在反射这种类型的时候会稍有不同。
			public native Class<?> getComponentType();// Class 类中的非静态方法，返回数组 Class 实例元素的基本类型，只有当前的 Class 对象代表的是一个数组类型的时候，该方法才会返回数组的元素实际类型，其他的任何时候都会返回 null。
			代表数组的这个由虚拟机动态创建的类型，它直接继承的 Object 类，并且所有有关数组类的操作，比如为某个元素赋值或是获取数组长度的操作都直接对应一个单独的虚拟机数组操作指令。
			同样也因为数组类直接由虚拟机运行时动态创建，所以你不可能从一个数组类型的 Class 实例中得到构造方法，编译器根本没机会为类生成默认的构造器。于是你也不能以常规的方法通过 Constructor 来创建一个该类的实例对象。
			当然不是，Java 中有一个类 java.lang.reflect.Array 提供了一些静态的方法用于动态的创建和获取一个数组类型：
				//创建一个一维数组，componentType 为数组元素类型，length 数组长度
				public static Object newInstance(Class<?> componentType, int length)
				//可变参数 dimensions，指定多个维度的单维度长度
				public static Object newInstance(Class<?> componentType, int... dimensions)
			完全是因为数组这种类型并不是由常规的编译器编译生成，而是由虚拟机动态创建的，所以想要通过反射的方式实例化一个数组类型是得依赖 Array 这个类型的相关 newInstance 方法的。
		六、反射与泛型：
			泛型是 Java 编译器范围内的概念，它能够在程序运行之前提供一定的安全检查，而反射是运行时发生的，也就是说如果你反射调用一个泛型方法，实际上就绕过了编译器的泛型检查了。我们看一段代码：
				ArrayList<Integer> list = new ArrayList<>();
				list.add(23);
				//list.add("fads");编译不通过
				Class<?> cls = list.getClass();
				Method add = cls.getMethod("add",Object.class);
				add.invoke(list,"hello");
				System.out.println(list.get(1));

				最终你会发现我们从整型容器中取出一个字符串，因为虚拟机只管在运行时从方法区找到 ArrayList 这个类的类型信息并解析出它的 add 方法，接着执行这个方法。
				它不像一般的方法调用，调用之前编译器会检测这个方法存在不存在，参数类型是否匹配等，所以没了编译器的这层安全检查，反射地调用方法更容易遇到问题。
				除此之外，之前我们说过的泛型在经过编译期之后会被类型擦除，但实际上代表该类型的 Class 类型信息中是保存有一些基本的泛型信息的，这一点我们可以通过反射得到。
	11、final 修饰的非静态全局变量只能通过直接赋值、构造函数中赋值、代码块{}中赋值三种方式赋值，且必须要赋值。
	   final 修饰的静态全局常亮不能通过构造函数赋值，因为静态常亮优先于构造函数初始化，只能通过直接赋值、静态代码块中赋值。
	12、反射中，Class.forName 和 ClassLoader 区别
		java中class.forName() 和 classLoader 都可用来对类进行加载。
		class.forName() 前者除了将类的 .class 文件加载到 jvm 中之外，还会对类进行解释，执行类中的 static 块，且对静态变量赋值（如果可以的话，比如一个静态变量由一个静态方法直接赋值）。
		而 classLoader 只干一件事情，就是将 .class 文件加载到 jvm 中，不会执行 static 中的内容,只有在 newInstance 才会去执行 static 块。
		Class.forName(name, initialize, loader) 带参函数也可控制是否加载 static 块。并且只有调用了 newInstance() 方法采用调用构造函数，创建类的对象。

		ClassLoader 就是遵循双亲委派模型最终调用启动类加载器的类加载器，实现的功能是“通过一个类的全限定名来获取描述此类的二进制字节流”，获取到二进制流后放到JVM中。Class.forName() 方法实际上也是调用的 CLassLoader 来实现的。
		下面结合着类装载机制阐述一下原理：
		Java 类装载过程：
			——>加载——>验证——>准备——>解析——>初始化——>使用——>卸载   其中 验证+准备+链接 环节属于链接范畴。
			装载：通过类的全限定名（com.codetop.***.User）获取二进制字节流，将二进制字节流转换成方法区中的运行时数据结构，在内存中生成 Java.lang.Class 对象；
			链接：执行下面的验证、准备和解析步骤，其中解析步骤是可以选择的：
				校验：检查导入类或接口的二进制数据的正确性；（文件格式验证，元数据验证，字节码验证，符号引用验证）；
				准备：给类的静态变量分配并初始化存储空间；
				解析：将常量池中的符号引用转成直接引用；
			初始化：激活类的静态变量，初始化 Java 代码和静态 Java 代码块，并初始化程序员设置的变量值。
			ClassLoader.loadClass(className) 方法，内部实际调用的方法是  ClassLoader.loadClass(className,false)，第2个 boolean参数，表示目标对象是否进行链接，false表示不进行链接，由上面介绍可以，
			不进行链接意味着不进行包括初始化等一些列步骤，那么静态块和静态对象就不会得到执行。
			扩展内容见：https://www.jianshu.com/p/52c38cf2e3d4
	13、cloneable 接口实现原理，浅拷贝 or 深拷贝
		对一个对象 a 的 clone 就是在堆上分配一个和 a 在堆上所占存储空间一样大的一块地方，然后把 a 的堆上内存的内容复制到这个新分配的内存空间上。
		
		支持克隆的类需要实现 Cloneable 接口，这样才能通过 Object 类的 clone 方法：protected native Object clone() throws CloneNotSupportedException;
		否认抛 CloneNotSupportedException 异常。
		
		浅克隆：
			即很表层的克隆，如果我们要克隆对象，只克隆它自身以及它所包含的所有对象的引用地址
		深克隆：
			克隆除自身对象以外的所有对象，包括自身所包含的所有对象实例
		所有的基本数据类型，无论是浅克隆还是深克隆，都会进行原值克隆，毕竟它们都不是对象，不是存储在堆中的。
		
		Object 的 clone() 方法，提供的是一种浅克隆的机制，如果想要实现对对象的深克隆，在不引入第三方 jar 包的情况下，可以使用两种办法：
			先对对象进行序列化，紧接着马上反序列化出；
			先调用 super.clone() 方法克隆出一个新对象来，然后在子类的 clone() 方法中手动给克隆出来的非基本数据类型（引用类型）赋值，比如 ArrayList 的 clone() 方法；
		
		clone 对 string 是深克隆，虽然 clone String 时拷贝其地址引用。但是在修改时，它会从字符串池中重新生成一个新的字符串，原有的对象保持不变。
		
			深拷贝时，如果一个对象中有多个属性是其他的对象引用或者引用较深或可能依赖第三方的 jar 包，这时如果通过手动一个个的调用 clone 方法继续拧拷贝时，工作量会比较大，而且可靠性也不能保证。
		如果是这种情况则建议采用示例3的做法，使用序列化 clone：
			public class CloneUtils {
			    public static <T extends Serializable> T clone(T obj){
			        T cloneObj = null;
			        try {
			            //写入字节流
			            ByteArrayOutputStream out = new ByteArrayOutputStream();
			            ObjectOutputStream obs = new ObjectOutputStream(out);
			            obs.writeObject(obj);
			            obs.close();
			            //分配内存，写入原始对象，生成新对象
			            ByteArrayInputStream ios = new ByteArrayInputStream(out.toByteArray());
			            ObjectInputStream ois = new ObjectInputStream(ios);
			            //返回生成的新对象
			            cloneObj = (T) ois.readObject();
			            ois.close();
			        } catch (Exception e) {
			            e.printStackTrace();
			        }
			        return cloneObj;
			    }
			}

		object clone的实际用途：
			精心设计一个浅克隆对象被程序缓存，作为功能模块模板；每次有用户调用这个模块则将可变部分替换成用户需要的信息即可。
			给同组的用户发送邮件，邮件内容相同（不可变）发送的用户不同（可变）。

	14、Java NIO 使用，简述 NIO 的最佳实践，比如 netty，mina
	15、hashtable 和 hashmap 的区别及实现原理，hashmap 会问到数组索引，hash 碰撞怎么解决
	16、String，Stringbuffer，StringBuilder 的区别？
	17、TreeMap 的实现原理：
		可直接参考：https://www.jianshu.com/p/fc5e16b5c674
		TreeMap:基于红黑树实现的，TreeMap 是有序的。同时红黑树更是一颗自平衡的排序二叉树。
		因为设计到 key 之间的比较进行排序，所以 key 不允许为 null。
		TreeMap 的基本操作 containsKey、get、put 和 remove 的时间复杂度是 log(n) 。
		另外，TreeMap 是非同步的。 它的 iterator 方法返回的迭代器是 fail-fast 的。	
		首先分析一下红黑树的特性：
			特点：
				·每个节点都只能是红色或者黑色
				·根节点是黑色
				·每个叶节点（NIL节点，空节点）是黑色的
				·如果一个结点是红的，则它两个子节点都是黑的。也就是说在一条路径上不能出现相邻的两个红色结点
				·从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点
			这些约束强制了红黑树的关键性质: 从根到叶子的最长的可能路径不多于最短的可能路径的两倍长。
			因为操作比如插入、删除和查找某个值的最坏情况时间都要求与树的高度成比例，这个在高度上的理论上限允许红黑树在最坏情况下都是高效的，而不同于普通的二叉查找树。所以红黑树它是复杂而高效的，其检索效率O(log n)。
		主要函数解析：
			===================================================================================================
			==============================================Entry================================================
			===================================================================================================
			Entry 是树的节点类:
					static final class Entry<K,V> implements Map.Entry<K,V> {
				        K key;
				        V value;
				        // 左孩子节点
				        Entry<K,V> left = null;
				        // 右孩子节点
				        Entry<K,V> right = null;
				        // 父节点
				        Entry<K,V> parent;
				        // 红黑树用来表示节点颜色的属性，默认为黑色
				        boolean color = BLACK;

				        /**
				         * 用key，value和父节点构造一个Entry，默认为黑色
				         */
				        Entry(K key, V value, Entry<K,V> parent) {
				            this.key = key;
				            this.value = value;
				            this.parent = parent;
				        }
				        ...
				        // 重写了 equals 和 hashCode 方法，利于比较是否相等
				        public boolean equals(Object o) {
				            if (!(o instanceof Map.Entry))
				                return false;
				            Map.Entry<?,?> e = (Map.Entry<?,?>)o;

				            return valEquals( key,e.getKey()) && valEquals( value,e.getValue());
				        }

				        public int hashCode() {
				            int keyHash = (key ==null ? 0 : key.hashCode());
				            int valueHash = (value ==null ? 0 : value.hashCode());
				            return keyHash ^ valueHash;
				        }
				        ...
				    }
			===================================================================================================
			===============================================put=================================================
			===================================================================================================
			一、将一个节点添加到红黑树中，通常需要下面几个步骤：
				a.将红黑树当成一颗二叉查找树，将节点插入。因为红黑树本身就是一个二叉查找树。
				b.将新插入的节点设置为红色
					为什么新插入的节点一定要是红色的，因为新插入节点为红色，不会违背红黑规则第（5）条，少违背一条就少处理一种情况。
				c.通过旋转和着色，使它恢复平衡，重新变成一颗符合规则的红黑树。
			二、对比下红黑树的规则和新插入节点后的情况，看下新插入节点会违背哪些规则：
				节点是红色或黑色：NO
				根节点是黑色：NO
				每个叶节点（NIL节点，空节点）是黑色的：NO
				每个红色节点的两个子节点都是黑色。(从每个叶子到根的所有路径上不能有两个连续的红色节点)：YES
					这一点是有可能违背的，我们将新插入的节点都设置成红色，如果其父节点也是红色的话，那就产生冲突了。
				从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点：NO
			三、添加新节点的过程有哪几种情况：
				新插入节点为根节点。这种情况直接将新插入节点设置为根节点即可，无需进行后续的旋转和着色处理。
				新插入节点的父节点是黑色。这种情况直接将新节点插入即可，不会违背规则（4）。
				新插入节点的父节点是红色。这种情况会违背规则（4），而这种情况又分为了以下三种：
					a.新插入节点N的父节点P和叔叔节点U都是红色。方法是：将祖父节点G设置为红色，父节点P和叔叔节点U设置为黑色，这时候就看似平衡了。但是，如果祖父节点G的父节点也是红色，这时候又违背规则（4）了，怎么办？
						方法是：将GPUN这一组看成一个新的节点，按照前面的方案递归；又但是根节点为红就违反规则（2）了，怎么办，方法是直接将根节点设置为黑色（两个连续黑色是没问题的）。
					b.新插入节点N的父节点P是红色，叔叔节点U是黑色或者缺少，且新节点N是P的右孩子。方法是：左旋父节点P。左旋后N和P角色互换，但是P和N还是连续的两个红色节点，还没有平衡，怎么办，看第三种情况。
					c.新插入节点N的父节点P是红色，叔叔节点U是黑色或者缺少，且新节点N是P的左孩子。方法是：右旋祖父节点G，然后将P设置为黑色，G设置为红色，达到平衡。此时父节点P是黑色，所以不用担心P的父节点是红色。
					当然上面说的三种情况都是基于一个前提：新插入节点N的父节点P是祖父节点G的左孩子，如果P是G的右孩子又是什么情况呢？其实情况和上面是相似的，只需要调整左旋还是右旋。
			TreeMap 实现：
				public V put(K key, V value) {
			        // 根节点
			        Entry<K,V> t = root;
			        // 如果根节点为空，则直接创建一个根节点，返回
			        if (t == null) {
			            root = new Entry<K,V>(key, value, null);
			            size = 1;
			            modCount++;
			            return null;
			        }
			        // 记录比较结果
			        int cmp;
			        Entry<K,V> parent;
			        // split comparator and comparable paths
			        // 当前使用的比较器
			        Comparator<? super K> cpr = comparator ;
			        // 如果比较器不为空，就是用指定的比较器来维护TreeMap的元素顺序
			        if (cpr != null) {
			             // do while循环，查找key要插入的位置（也就是新节点的父节点是谁）
			            do {
			                // 记录上次循环的节点t
			                parent = t;
			                // 比较当前节点的key和新插入的key的大小
			                cmp = cpr.compare(key, t. key);
			                 // 新插入的key小的话，则以当前节点的左孩子节点为新的比较节点
			                if (cmp < 0)
			                    t = t. left;
			                // 新插入的key大的话，则以当前节点的右孩子节点为新的比较节点
			                else if (cmp > 0)
			                    t = t. right;
			                else
			              // 如果当前节点的key和新插入的key想的的话，则覆盖map的value，返回
			                    return t.setValue(value);
			            // 只有当t为null，也就是没有要比较节点的时候，代表已经找到新节点要插入的位置
			            } while (t != null);
			        }
			        else {
			            // 如果比较器为空，则使用key作为比较器进行比较
			            // 这里要求key不能为空，并且必须实现Comparable接口
			            if (key == null)
			                throw new NullPointerException();
			            Comparable<? super K> k = (Comparable<? super K>) key;
			            // 和上面一样，喜欢查找新节点要插入的位置
			            do {
			                parent = t;
			                cmp = k.compareTo(t. key);
			                if (cmp < 0)
			                    t = t. left;
			                else if (cmp > 0)
			                    t = t. right;
			                else
			                    return t.setValue(value);
			            } while (t != null);
			        }
			        // 找到新节点的父节点后，创建节点对象
			        Entry<K,V> e = new Entry<K,V>(key, value, parent);
			        // 如果新节点key的值小于父节点key的值，则插在父节点的左侧
			        if (cmp < 0)
			            parent. left = e;
			        // 如果新节点key的值大于父节点key的值，则插在父节点的右侧
			        else
			            parent. right = e;
			        // 插入新的节点后，为了保持红黑树平衡，对红黑树进行调整
			        fixAfterInsertion(e);
			        // map元素个数+1
			        size++;
			        modCount++;
			        return null;
			    }

			    private static <K, V> void setColor(TreeMap.Entry<K, V> p, boolean c) {
			        if (p != null)
			            p.color = c;
			    }

			    private static <K, V> TreeMap.Entry<K, V> parentOf(TreeMap.Entry<K, V> p) {
			        return (p == null ? null : p.parent);
			    }

			    private static <K, V> TreeMap.Entry<K, V> leftOf(TreeMap.Entry<K, V> p) {
			        return (p == null) ? null : p.left;
			    }

			    private static <K, V> TreeMap.Entry<K, V> rightOf(TreeMap.Entry<K, V> p) {
			        return (p == null) ? null : p.right;
			    }

			    private static <K, V> boolean colorOf(TreeMap.Entry<K, V> p) {
			        return (p == null ? BLACK : p.color);
			    }

			    /**
			     * 对红黑树的节点(x)进行左旋转
			     *
			     * 左旋示意图(对节点x进行左旋)：
			     *      px                              px
			     *     /                               /
			     *    x                               y               
			     *   /  \      --(左旋)--           / \                
			     *  lx   y                          x  ry    
			     *     /   \                       /  \
			     *    ly   ry                     lx  ly 
			     *
			     */
			    private void rotateLeft(Entry<K, V> p) {
			        if (p != null) {
			            // 取得要选择节点p的右孩子
			            Entry<K, V> r = p.right;
			            // "p"和"r的左孩子"的相互指向...
			            // 将"r的左孩子"设为"p的右孩子"
			            p.right = r.left;
			            // 如果r的左孩子非空，将"p"设为"r的左孩子的父亲"
			            if (r.left != null)
			                r.left.parent = p;

			            // "p的父亲"和"r"的相互指向...
			            // 将"p的父亲"设为"y的父亲"
			            r.parent = p.parent;
			            // 如果"p的父亲"是空节点，则将r设为根节点
			            if (p.parent == null)
			                root = r;
			                // 如果p是它父节点的左孩子，则将r设为"p的父节点的左孩子"
			            else if (p.parent.left == p)
			                p.parent.left = r;
			            else
			                // 如果p是它父节点的左孩子，则将r设为"p的父节点的左孩子"
			                p.parent.right = r;
			            // "p"和"r"的相互指向...
			            // 将"p"设为"r的左孩子"
			            r.left = p;
			            // 将"p的父节点"设为"r"
			            p.parent = r;
			        }
			    }
			    
			    /**
			     * 对红黑树的节点进行右旋转
			     *
			     * 右旋示意图(对节点y进行右旋)：
			     *            py                               py
			     *           /                                /
			     *          y                                x                 
			     *         /  \      --(右旋)--            /  \                     
			     *        x   ry                           lx   y 
			     *       / \                                   / \                   
			     *      lx  rx                                rx  ry
			     *
			     */
			    private void rotateRight(Entry<K, V> p) {
			        if (p != null) {
			            // 取得要选择节点p的左孩子
			            Entry<K, V> l = p.left;
			            // 将"l的右孩子"设为"p的左孩子"
			            p.left = l.right;
			            // 如果"l的右孩子"不为空的话，将"p"设为"l的右孩子的父亲"
			            if (l.right != null) l.right.parent = p;
			            // 将"p的父亲"设为"l的父亲"
			            l.parent = p.parent;
			            // 如果"p的父亲"是空节点，则将l设为根节点
			            if (p.parent == null)
			                root = l;
			                // 如果p是它父节点的右孩子，则将l设为"p的父节点的右孩子"
			            else if (p.parent.right == p)
			                p.parent.right = l;
			                //如果p是它父节点的左孩子，将l设为"p的父节点的左孩子"
			            else p.parent.left = l;
			            // 将"p"设为"l的右孩子"
			            l.right = p;
			            // 将"l"设为"p父节点"
			            p.parent = l;
			        }
			    }
			    
			    /**
			     * 新增节点后对红黑树的调整方法
			     */
			    private void fixAfterInsertion(Entry<K, V> x) {
			        // 将新插入节点的颜色设置为红色
			        x.color = RED;
			        // while循环，保证新插入节点x不是根节点或者新插入节点x的父节点不是红色（这两种情况不需要调整）
			        while (x != null && x != root && x.parent.color == RED) {
			            // 如果新插入节点x的父节点是祖父节点的左孩子
			            if (parentOf(x) == leftOf(parentOf(parentOf(x)))) {
			                // 取得新插入节点x的叔叔节点
			                Entry<K, V> y = rightOf(parentOf(parentOf(x)));
			                // 如果新插入x的叔叔节点是红色-------------------①
			                if (colorOf(y) == RED) {
			                    // 将x的父节点设置为黑色
			                    setColor(parentOf(x), BLACK);
			                    // 将x的叔叔节点设置为黑色
			                    setColor(y, BLACK);
			                    // 将x的祖父节点设置为红色
			                    setColor(parentOf(parentOf(x)), RED);
			                    // 将x指向祖父节点，如果x的祖父节点的父节点是红色，按照上面的步奏继续循环
			                    x = parentOf(parentOf(x));
			                } else {
			                    // 如果新插入x的叔叔节点是黑色或缺少，且x的父节点是祖父节点的右孩子-------------------②
			                    if (x == rightOf(parentOf(x))) {
			                        // 左旋父节点
			                        x = parentOf(x);
			                        rotateLeft(x);
			                    }
			                    // 如果新插入x的叔叔节点是黑色或缺少，且x的父节点是祖父节点的左孩子-------------------③
			                    // 将x的父节点设置为黑色
			                    setColor(parentOf(x), BLACK);
			                    // 将x的祖父节点设置为红色
			                    setColor(parentOf(parentOf(x)), RED);
			                    // 右旋x的祖父节点
			                    rotateRight(parentOf(parentOf(x)));
			                }
			            } else { // 如果新插入节点x的父节点是祖父节点的右孩子，下面的步奏和上面的相似，只不过左旋右旋的区分，不在细讲
			                Entry<K, V> y = leftOf(parentOf(parentOf(x)));
			                if (colorOf(y) == RED) {
			                    setColor(parentOf(x), BLACK);
			                    setColor(y, BLACK);
			                    setColor(parentOf(parentOf(x)), RED);
			                    x = parentOf(parentOf(x));
			                } else {
			                    if (x == leftOf(parentOf(x))) {
			                        x = parentOf(x);
			                        rotateRight(x);
			                    }
			                    setColor(parentOf(x), BLACK);
			                    setColor(parentOf(parentOf(x)), RED);
			                    rotateLeft(parentOf(parentOf(x)));
			                }
			            }
			        }
			        // 最后将根节点设置为黑色，不管当前是不是红色，反正根节点必须是黑色
			        root.color = BLACK;
			    }
			 ===================================================================================================
			==============================================remove===============================================
			===================================================================================================
			相比添加，红黑树的删除显得更加复杂了。看下红黑树的删除需要哪几个步奏：
				a.将红黑树当成一颗二叉查找树，将节点删除
				b.通过旋转和着色，使它恢复平衡，重新变成一颗符合规则的红黑树
			删除节点的关键是：
				a.如果删除的是红色节点，不会违背红黑树的规则
				b.如果删除的是黑色节点，那么这个路径上就少了一个黑色节点，则违背了红黑树的规则
			来看下红黑树删除节点会有哪几种情况：
				a.被删除的节点没有孩子节点，即叶子节点。可直接删除。
				b.被删除的节点只有一个孩子节点，那么直接删除该节点，然后用它的孩子节点顶替它的位置。
				c.被删除的节点有两个孩子节点。这种情况二叉树的删除有一个技巧，就是查找到要删除的节点X，接着我们找到它左子树的最大元素M，或者它右子树的最小元素M，交换X和M的值，然后删除节点M。
					此时M就最多只有一个子节点N(若是左子树则没有右子节点，若是右子树则没有左子节点)，若M没有孩子则进入(1)的情况，否则进入(2)的情况。

				红黑树的删除遇到的主要问题就是被删除路径上的黑色节点减少，于是需要进行一系列旋转和着色，比如节点X（需要删除的节点）和M节点的值互换后，将M点删除，如果M是黑色，则红黑树路径上就少了一个黑色节点，这违背了第五条：从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点，
			当然上面的情况是基于M是X右子树的最小元素，而M如果是X左子树的最大元素和上面的情况是相似的。

			所以就需要在此基础上继续根据兄弟节点、兄弟节点的孩子节点及父节点的红黑色情况做进一步的颜色替换和左旋或右旋操作，来使整棵树重新达到平衡。

			接下来看下函数：
				public V remove(Object key) {
			        // 根据key查找到对应的节点对象
			        Entry<K,V> p = getEntry(key);
			        if (p == null)
			            return null;

			        // 记录key对应的value，供返回使用
			        V oldValue = p. value;
			        // 删除节点
			        deleteEntry(p);
			        return oldValue;
			    }

			     
			private void deleteEntry(Entry<K,V> p) {
			        modCount++;
			        // map容器的元素个数减一
			        size--;

			        // If strictly internal, copy successor's element to p and then make p
			        // point to successor.
			        // 如果被删除的节点p的左孩子和右孩子都不为空，则查找其替代节点-----------这里表示要删除的节点有两个孩子（3）
			        if (p.left != null && p. right != null) {
			            // 查找p的替代节点
			            Entry<K,V> s = successor (p);
			            p. key = s.key ;
			            p. value = s.value ;
			            // 将p指向替代节点，※※※※※※从此之后的p不再是原先要删除的节点p，而是替代者p（就是图解里面讲到的M） ※※※※※※
			            p = s;
			        } // p has 2 children

			        // Start fixup at replacement node, if it exists.
			        // replacement为替代节点p的继承者（就是图解里面讲到的N），p的左孩子存在则用p的左孩子替代，否则用p的右孩子
			        Entry<K,V> replacement = (p. left != null ? p.left : p. right);
			 
			        if (replacement != null) { // 如果上面的if有两个孩子不通过--------------这里表示要删除的节点只有一个孩子（2）
			            // Link replacement to parent
			            // 将p的父节点拷贝给替代节点
			            replacement. parent = p.parent ;
			            // 如果替代节点p的父节点为空，也就是p为跟节点，则将replacement设置为根节点
			            if (p.parent == null)
			                root = replacement;
			            // 如果替代节点p是其父节点的左孩子，则将replacement设置为其父节点的左孩子
			            else if (p == p.parent. left)
			                p. parent.left   = replacement;
			            // 如果替代节点p是其父节点的左孩子，则将replacement设置为其父节点的右孩子
			            else
			                p. parent.right = replacement;

			            // Null out links so they are OK to use by fixAfterDeletion.
			            // 将替代节点p的left、right、parent的指针都指向空，即解除前后引用关系（相当于将p从树种摘除），使得gc可以回收
			            p. left = p.right = p.parent = null;

			            // Fix replacement
			            // 如果替代节点p的颜色是黑色，则需要调整红黑树以保持其平衡
			            if (p.color == BLACK)
			                fixAfterDeletion(replacement);
			        } else if (p.parent == null) { // return if we are the only node.
			            // 如果要替代节点p没有父节点，代表p为根节点，直接删除即可
			            root = null;
			        } else { //  No children. Use self as phantom replacement and unlink.
			            // 判断进入这里说明替代节点p没有孩子--------------这里表示没有孩子则直接删除（1）
			            // 如果p的颜色是黑色，则调整红黑树
			            if (p.color == BLACK)
			                fixAfterDeletion(p);
			            // 下面删除替代节点p
			            if (p.parent != null) {
			                // 解除p的父节点对p的引用
			                if (p == p.parent .left)
			                    p. parent.left = null;
			                else if (p == p.parent. right)
			                    p. parent.right = null;
			                // 解除p对p父节点的引用
			                p. parent = null;
			            }
			        }
			    }

			    /**
			     * 查找要删除节点的替代节点
			     */
			    static <K,V> TreeMap.Entry<K,V> successor(Entry<K,V> t) {
			        if (t == null)
			            return null;
			        // 查找右子树的最左孩子
			        else if (t.right != null) {
			            Entry<K,V> p = t. right;
			            while (p.left != null)
			                p = p. left;
			            return p;
			        } else { // 查找左子树的最右孩子
			            Entry<K,V> p = t. parent;
			            Entry<K,V> ch = t;
			            while (p != null && ch == p. right) {
			                ch = p;
			                p = p. parent;
			            }
			            return p;
			        }
			    }

			    /** From CLR */
			    private void fixAfterDeletion(Entry<K,V> x) {
			        // while循环，保证要删除节点x不是跟节点，并且是黑色（根节点和红色不需要调整）
			        while (x != root && colorOf (x) == BLACK) {
			            // 如果要删除节点x是其父亲的左孩子
			            if (x == leftOf( parentOf(x))) {
			                // 取出要删除节点x的兄弟节点
			                Entry<K,V> sib = rightOf(parentOf (x));

			                // 如果删除节点x的兄弟节点是红色---------------------------①
			                if (colorOf(sib) == RED) {
			                    // 将x的兄弟节点颜色设置为黑色
			                    setColor(sib, BLACK);
			                    // 将x的父节点颜色设置为红色
			                    setColor(parentOf (x), RED);
			                    // 左旋x的父节点
			                    rotateLeft( parentOf(x));
			                    // 将sib重新指向旋转后x的兄弟节点 ，进入else的步奏③
			                    sib = rightOf(parentOf (x));
			                }

			                // 如果x的兄弟节点的两个孩子都是黑色-------------------------③
			                if (colorOf(leftOf(sib))  == BLACK &&
			                    colorOf(rightOf (sib)) == BLACK) {
			                    // 将兄弟节点的颜色设置为红色
			                    setColor(sib, RED);
			                    // 将x的父节点指向x，如果x的父节点是黑色，需要将x的父节点整天看做一个节点继续调整-------------------------②
			                    x = parentOf(x);
			                } else {
			                    // 如果x的兄弟节点右孩子是黑色，左孩子是红色-------------------------④
			                    if (colorOf(rightOf(sib)) == BLACK) {
			                        // 将x的兄弟节点的左孩子设置为黑色
			                        setColor(leftOf (sib), BLACK);
			                        // 将x的兄弟节点设置为红色
			                        setColor(sib, RED);
			                        // 右旋x的兄弟节点
			                        rotateRight(sib);
			                        // 将sib重新指向旋转后x的兄弟节点，进入步奏⑤
			                        sib = rightOf(parentOf (x));
			                    }
			                    // 如果x的兄弟节点右孩子是红色-------------------------⑤
			                    setColor(sib, colorOf (parentOf(x)));
			                    // 将x的父节点设置为黑色
			                    setColor(parentOf (x), BLACK);
			                    // 将x的兄弟节点的右孩子设置为黑色
			                    setColor(rightOf (sib), BLACK);
			                    // 左旋x的父节点
			                    rotateLeft( parentOf(x));
			                    // 达到平衡，将x指向root，退出循环
			                    x = root;
			                }
			            } else { // symmetric // 如果要删除节点x是其父亲的右孩子，和上面情况一样，这里不再细讲
			                Entry<K,V> sib = leftOf(parentOf (x));

			                if (colorOf(sib) == RED) {
			                    setColor(sib, BLACK);
			                    setColor(parentOf (x), RED);
			                    rotateRight( parentOf(x));
			                    sib = leftOf(parentOf (x));
			                }

			                if (colorOf(rightOf(sib)) == BLACK &&
			                    colorOf(leftOf (sib)) == BLACK) {
			                    setColor(sib, RED);
			                    x = parentOf(x);
			                } else {
			                    if (colorOf(leftOf(sib)) == BLACK) {
			                        setColor(rightOf (sib), BLACK);
			                        setColor(sib, RED);
			                        rotateLeft(sib);
			                        sib = leftOf(parentOf (x));
			                    }
			                    setColor(sib, colorOf (parentOf(x)));
			                    setColor(parentOf (x), BLACK);
			                    setColor(leftOf (sib), BLACK);
			                    rotateRight( parentOf(x));
			                    x = root;
			                }
			            }
			        }

			        setColor(x, BLACK);
			    }
			===================================================================================================
			===============================================get=================================================
			===================================================================================================
			红黑树的查询，逻辑相对简单：
				public V get(Object key) {
			        Entry<K, V> p = getEntry(key);
			        return (p == null ? null : p.value);
			    }

			    final Entry<K, V> getEntry(Object key) {
			        if (comparator != null)
			            return getEntryUsingComparator(key);
			        if (key == null)
			            throw new NullPointerException();
			        Comparable<? super K> k = (Comparable<? super K>) key;
			        Entry<K, V> p = root;
			        while (p != null) {
			            int cmp = k.compareTo(p.key);
			            if (cmp < 0)
			                p = p.left;
			            else if (cmp > 0)
			                p = p.right;
			            else
			                return p;
			        }
			        return null;
			    }

			    final Entry<K, V> getEntryUsingComparator(Object key) {
			        K k = (K) key;
			        Comparator<? super K> cpr = comparator;
			        if (cpr != null) {
			            Entry<K, V> p = root;
			            while (p != null) {
			                int cmp = cpr.compare(k, p.key);
			                if (cmp < 0)
			                    p = p.left;
			                else if (cmp > 0)
			                    p = p.right;
			                else
			                    return p;
			            }
			        }
			        return null;
			    }

			==================================================Ite=================================================
			======================================================================================================
			======================================================================================================
			通过Iterator遍历key-value：
				Iterator iter = tmap.entrySet().iterator();
		        while (iter.hasNext()) {
		            Map.Entry entry = (Map.Entry) iter.next();
		            System.out.printf("next : %s - %s\n", entry.getKey(), entry.getValue());
		        }
		    清空 TreeMap：
		    	public void clear() {
			        modCount++;
			        size = 0;
			        root = null;
			    }
			TreeMap 的子 Map 函数：
				tmap.headMap("c")
				tmap.headMap("c", true)
				tmap.headMap("c", false)
				tmap.tailMap("c")
				tmap.tailMap("c", true)
				tmap.tailMap("c", false)
				tmap.subMap("a", "c")
				tmap.subMap("a", true, "c", true)
				tmap.subMap("a", true, "c", false)
				tmap.subMap("a", false, "c", true)
				tmap.subMap("a", false, "c", false)
				tmap.navigableKeySet()
				tmap.descendingKeySet()
				tmap.firstKey()
				tmap.firstEntry()
				tMap.lastKey()
				tMap.lastEntry()
				tMap.floorKey("bbb")// 获取“小于/等于bbb”的最大键值对
				tMap.lowerKey("bbb")// 获取“小于bbb”的最大键值对
				tMap.ceilingKey("ccc")// 获取“大于/等于bbb”的最小键值对
				tMap.higherKey("ccc")// 获取“大于bbb”的最小键值对
			======================================================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
JVM相关
	1、类的实例化顺序，比如父类静态数据，构造函数，字段，子类静态数据，构造函数，字段，他们的执行顺序；类加载机制；
		一、类的实例化顺序（静态变量——>静态初始化块——>变量——>初始化块——>构造器）:
			其中，后三者是在调构造器时执行的。
			public class OrderInLoadTestDemo {
			    /* 静态变量 */
			    public static String staticField = "静态变量";
			    /* 静态初始化块 */
			    static {
			        System.out.println(staticField);
			        System.out.println("静态初始化块");
			    }
			    /* 变量 */
			    public String field = "变量";
			    /* 初始化块 */ 
			    {
			        System.out.println(field);
			        System.out.println("初始化块");
			    }
			    /* 构造器 */
			    public OrderInLoadTestDemo() {
			        System.out.println("构造器");
			    }
			    public static void main(String[] args) {
			        new OrderInLoadTestDemo();
			    }
			}	
		二、子类：
			父类--静态变量
			父类--静态初始化块
			子类--静态变量
			子类--静态初始化块
			子类main方法
			父类--变量
			父类--初始化块
			父类--构造器
			子类--变量
			子类--初始化块
			子类--构造器
		分析：
			(1)访问SubClass.main(),(这是一个static方法)，于是装载器就会为你寻找已经编译的SubClass类的代码（也就是SubClass.class文件）。在装载的过程中，装载器注意到它有一个基类（也就是extends所要表示的意思），于是它再装载基类。
				不管你创不创建基类对象，这个过程总会发生。如果基类还有基类，那么第二个基类也会被装载，依此类推。
			(2)执行根基类的static初始化，然后是下一个派生类的static初始化，依此类推。这个顺序非常重要，因为派生类的“static初始化”有可能要依赖基类成员的正确初始化。
			(3)当所有必要的类都已经装载结束，开始执行main()方法体，并用new SubClass（）创建对象。
			(4)类SubClass存在父类，则调用父类的构造函数，你可以使用super来指定调用哪个构造函数。基类的构造过程以及构造顺序，同派生类的相同。首先基类中各个变量按照字面顺序进行初始化，然后执行基类的构造函数的其余部分。
			(5)对子类成员数据按照它们声明的顺序初始化，执行子类构造函数的其余部分。
		另外：
			(1)通过子类引用父类的静态字段，不会导致子类初始化；
			(2)通过数组定义来引用类，不会触发此类的初始化；
			(3)常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化；
			第三种情况演示：
				public class ConstClass {
				    static {
				        System.out.println("ConstClass init!");
				    }
				    public static final String HELLOWORLD = "hello world";
				}
				public class Test {
				    public static void main(String[] args) {
				    	// 只会打印：hello world
				    	// 不会打印：ConstClass init!
				        System.out.println(ConstClass.HELLOWORLD);
				    }
				}
		三、类加载机制：
			类从被加载到虚拟机内存开始，到卸载出内存为止，它的生命周期包括7个阶段：加载、验证、准备、解析、初始化、使用和卸载。
			（1）加载：
				a.通过一个类的全限定名来获取定义此类的二进制字节流。
					从ZIP包中读取
					从网络中获取
					运行时计算生成(Java动态代理技术)
					由其他文件生成(由JSP文件生成对应的Class类)
					从数据库中读取
					......
				b.将二进制字节流存储在方法区中(按照虚拟机所需的格式存储)。
				c.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。Class对象比较特殊，存放在方法中(HotSpot虚拟机)。
				加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
			（2）验证：
				验证的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
				a.格式语义校验：
					是否以0xCAFEBASE开头
					主、次版本号是否在当前虚拟机处理范围内
					元数据验证
						对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
					字节码验证
						通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
					符号引用验证
						确保解析动作能正确执行。
				b.代码逻辑校验
				验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
			（3）准备：
				准备阶段正式为静态变量分配内存并设置初始值，这些静态变量在方法区中分配内存。
				准备阶段，JVM只会为静态变量(static修饰)分配内存，不包括实例变量，实例变量将会在对象实例化时随对象一起分配在Java堆中。
					准备阶段，只会为value分配内存，不会为name分配内存
					public static int value = 123;
					private String name = "Tom";
				设置初始值：
					通常情况(无final)：零值
						准备阶段，未执行任何Java方法，而value赋值为123指令是程序编译后，存放于类构造器方法中，在初始化阶段才会执行，因此准备阶段，会设置零值。
						public static int value = 123;
					特殊情况(有final)：实际值
						public static final int value = 123;
			（4）解析：
				解析阶段是虚拟机将常量池内的符号引用替换为直接在其内存中的直接引用的过程。
				JVM主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行解析。
			（5）初始化：
				在介绍初始化时，要先介绍两个方法：<clinit> 和 <init> :
					在编译生成class文件时，会自动产生两个方法，一个是类的初始化方法, 另一个是实例的初始化方法
					<clinit>：
						在jvm第一次加载class文件时调用，包括静态变量初始化语句和静态块的执行
					<init>：
						在实例创建出来的时候调用，包括调用 new 操作符；
						调用 Class 或Java.lang.reflect.Constructor 对象的 newInstance()方法；
						调用任何现有对象的 clone()方法；
						通过 java.io.ObjectInputStream 类的 getObject() 方法反序列化。

						类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备极端，变量已经付过一次系统要求的初始值，而在初始化阶段，
					则根据程序猿通过程序制定的主管计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器<clinit>()方法的过程.
						<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块 static{} 中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，
					静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
						static {
							i = 0;
							sout(i);// Illegal forward reference （不合法的向前引用）
						}
						static int i = 1;
						... main (...) {
							sout(i); // 结果为1
						}

					<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生产<clinit>()方法。
					接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。
					虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。
					如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。
					常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

				到了初始化阶段，才真正开始执行类中定义的Java程序代码。
				JVM规定有且仅有5种情况必须对类进行初始化：
					遇到new、 getstatic、 putstatic 或 invokestatic 这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。
					对应场景为：
						使用new关键字实例化对象
						读取或设置一个类的静态字段(final修饰的除外)
						调用一个类的静态方法
						使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发其初始化。
					当初始化一个类时，需要先初始化父类。
				当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的类)，虚拟机会先初始化这个类。
				当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
			（6）使用：
				当JVM完成初始化阶段之后，JVM便开始从入口方法开始执行用户的程序代码。
			（7）卸载：
				当用户程序代码执行完毕后，JVM便开始销毁创建的Class对象，最后负责运行的JVM也退出内存。
	2、JVM 内存分代
		系统的地址空间 可以划分为 内核空间 和用户空间。 
		内核空间主要是系统运行空间，包含连接系统硬件和调度程序 以及提供联网 和虚拟内存等服务C进程运行空间，而用户空间是Java程序实际运行时 所在内存空间。
		内存模型：
			JVM架构图中，其中类加载器（Class Loader）负责依据特定格式，加载class文件到内存；执行引擎（Execution Engine）负责 对命令进行解析；本地库接口（Native Interface） 负责融合不同开发语言的原生库为Java所用。
			运行时数据区包括：方法区、堆、虚拟机栈、本地方法栈、程序计数器，其中后三者为线程私有内存、前两者属于线程共享内存。
			程序计数器：
				（1）程序计数器  当前线程所执行的字节码行号指示器（逻辑）
				（2）CPU 改变计数器的值来选取下一条需要执行的字节码指令
				（3）和线程是一对一的关系即“线程私有”
				（4）对 java 方法计数，如果是 Native 方法则计数器值为 Undefined
				（5）不会发生内存泄漏
			虚拟机栈：
				（1）虚拟机栈 Java 方法执行的内存模型
				（2）虚拟机栈包含多个栈帧，其中每个方法执行都会创建一个栈帧并放入虚拟机栈，当方法执行完后再将该栈帧移除。
				（3）一个栈帧包括局部变量表、操作栈、动态连接、返回地址等
				（4）虚拟机栈有大小限制，当超出最大栈深度后，会发生SOF异常
				虚拟机栈 OutOfMemmoryError 异常场景：
					Xss 参数是设定虚拟机中每个线程占用的栈内存大小，而虚拟机栈可分配的内存又跟物理机的内存大小、Java堆内存、方法区等内存大小相关，其它的区分得的内存越大，虚拟机栈能够分得的内存就越小，并发的线程数量也就越小；
					而如果要想模拟 OOM 异常可以通过不停的创建线程，直到虚拟机栈内存被使用完。
			本地方法栈：
				与虚拟机栈相似，主要作用是标注了Native的方法
			方法区：
				方法区是 JVM 的一种规范，保存 java 类的相关信息(包括 Method、Filed 等）。 元空间 和永久代 都是方法区的实现。
				永久代（PermGen）：
					jdk8之前，使用永久代。永久代使用的是 JVM 内存。 但是从 jdk 7 开始，原先位于永久代中的字符串常量池被移入到堆内存中。
				元空间（MetaSpace）：
					jdk8开始 使用元空间替代永久代。元空间使用堆内存。
					元空间 相对永久代 具有如下优势：
						（1）字符串常量池存在永久代中，容易出现性能问题和内存溢出。
						（2）类和方法的信息大小难以确定，给永久代的大小指定困难
						（3）永久代会为 GC 带来不必要的复杂度
						（4）方便 HotSpot 与其他 JVM 如 Jrockit 的集成
			Java 堆：
				1，虚拟机启动时创建，被所有线程共享，是对象实例的分配区域
				2，GC管理的主要区域
				java内存模型中 堆 和 栈 的联系和区别
				联系：
					引用对象、数组时，栈里定义变量保存堆中目标的首地址
				区别：
					1，管理方式：栈自动释放，堆需要GC
					2，空间大小：栈比堆小
					3，碎片化： 栈产生的碎片 远小于堆
					4，分配方式： 栈支持静态和动态分配，而堆只支持动态分配
					5，效率：栈的效率比堆高
		intern()：
				当调用 intern() 方法时，如果字符串常量池先前已创建出该字符串常量，则返回池中的该字符串的引用。否则，如果该字符串对象已经存在Java堆中，则将堆中对此对象的引用添加到字符串常量池中，
			并且返回该引用；如果堆中不存在，则在池中创建该字符串并返回其引用。
		在 Java 的内存分配中，总共3种常量池：
			字符串常量池(String Constant Pool):
				在JDK6.0及之前版本，字符串常量池是放在Perm Gen区(也就是方法区)中；
				在JDK7.0版本，字符串常量池被移到了堆中了。至于为什么移到堆内，大概是由于方法区的内存空间太小了。
				在HotSpot VM里实现的 string pool 功能的是一个 StringTable 类，它是一个Hash表，默认值大小长度是1009；这个 StringTable 在每个 HotSpot VM 的实例只有一份，被所有的类共享。字符串常量由一个一个字符组成，放在了 StringTable 上。
				StringTable 的长度可以通过参数指定：-XX:StringTableSize=10000（默认是1009）
				String Pool里放的是字符串常量和放于堆内的字符串对象的引用。字符串常量池中的字符串只存在一份！
			class 常量池 (Class Constant Pool)：
					我们写的每一个Java类被编译后，就会形成一份class文件；class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池(constant pool table)，
				用于存放编译器生成的各种字面量(Literal)和符号引用(Symbolic References)；
					每个class文件都有一个class常量池。
				字面量包括：1.文本字符串 2.八种基本类型的值 3.被声明为final的常量等；
				符号引用包括：1.类和方法的全限定名 2.字段的名称和描述符 3.方法的名称和描述符。
			运行时常量池(Runtime Constant Pool)：
				运行时常量池存在于内存中，也就是 class 常量池被加载到内存之后的版本，不同之处是：它的字面量可以动态的添加(String#intern()),符号引用可以被解析为直接引用。
				JVM在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。而当类加载到内存中后，jvm 就会将 class 常量池中的内容存放到运行时常量池中，
				由此可知，运行时常量池也是每个类都有一个。在解析阶段，会把符号引用替换为直接引用，解析的过程会去查询字符串常量池，也就是我们上面所说的 StringTable，以保证运行时常量池所引用的字符串与字符串常量池中是一致的。
	3、Java 垃圾对象判断的标准
			当虚拟机发现该对象没有被其他对象引用时，则将该对象判断为可以回收的垃圾对象。检测对象是否为被其他对象引用可以使用 引用计数法，和可达性分析算法。
			引用计数法：执行效率高，程序执行受影响较小，无法检测出 循环引用的情况，导致内存泄漏。
			可达性分析算法（通过判断对象的引用链是否可达 来决定对象是否可以被回收）： 
				可以作为 GC root 的对象：
					（1）虚拟机栈中引用的对象（栈帧中的本地变量表）
					（2）方法区中的常量引用的对象
					（3）方法区中的类静态属性引用的对象
					（4）本地方法栈中JNI(Native方法）的引用对象
					（5）活跃线程的引用对象
	4、Java 8 的内存分代改进
		先阐述先方法区的实现——持久代的特点及其局限性：
			持久代（也叫永久代）是 HotSpot 的概念，指内存的永久保存区域。
			说说为什么会内存益出：
				这一部分用于存放 Class 和 Meta 的信息，Class 在被 Load 的时候被放入 PermGen space 区域，它和和存放 Instance 的 Heap 区域不同，所以如果你的 APP 会 LOAD 很多 CLASS 的话，就很可能出现 PermGen space 错误。
			持久代中包含了虚拟机中所有可通过反射获取到的数据，比如Class和Method对象。
			JVM用于描述应用程序中用到的类和方法的元数据也存储在持久代中。JVM运行时会用到多少持久代的空间取决于应用程序用到了多少类。除此之外，Java SE库中的类和方法也都存储在这里。
			如果JVM发现有的类已经不再需要了，它会去回收（卸载）这些类，将它们的空间释放出来给其它类使用。Full GC会进行持久代的回收。
			持久代的大小：
				它的上限是 MaxPermSize ，默认是64M。
				需要多大的持久代空间取决于类的数量，方法的大小，以及常量池的大小。
			为什么移除持久代：
				它的大小是在启动时固定好的——很难进行调优。-XX:PermSize和-XX:MaxPermSize来指定最小值和最大值。
				HotSpot的内部类型也是Java对象：它可能会在Full GC中被移动，同时它对应用不透明，且是非强类型的，难以跟踪调试，还需要存储元数据的元数据信息（meta-metadata）。
				简化Full GC：每一个回收器有专门的元数据迭代器。
				可以在GC不进行暂停的情况下并发地释放类数据。
		根据上面的各种原因，永久代最终被移除，方法区移至Metaspace，字符串常量移至Java Heap。
		移除持久代后，这部分内存空间将全部移除。JVM的参数：PermSize 和 MaxPermSize 会被忽略并给出警告（如果在启用时设置了这两个参数）。
		元空间（MetaSpace 也是本地内存（Native memory））：
			JDK 8的HotSpot JVM现在使用的是本地内存来表示类的元数据，这个区域就叫做元空间。
			在JDK1.8中，永久代已经不存在，存储的类信息、编译后的代码数据等已经移动到了MetaSpace（元空间）中，元空间并没有处于堆内存上。
			这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace) (运行常量池在直接内存元空间中，字符串常量池在堆中)。
			元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小： 
				-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。 
				-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。 
				-verbose 参数是为了获取类型加载和卸载的信息。
			元空间由 Klass Metaspace 和 NoKlass Metaspace 组成。
				Klass Metaspace:
					Klass Metaspace就是用来存klass的，klass是我们熟知的class文件在jvm里的运行时数据结构，不过有点要提的是我们看到的类似A.class其实是存在heap里的，是java.lang.Class的一个对象实例。
					这块内存是紧接着Heap的，和我们之前的perm一样，这块内存大小可通过-XX:CompressedClassSpaceSize参数来控制，这个参数前面提到了默认是1G。
				NoKlass Metaspace:
					NoKlass Metaspace专门来存klass相关的其他的内容，比如method，constantPool等，这块内存是由多块内存组合起来的，所以可以认为是不连续的内存块组成的。这块内存是必须的，虽然叫做NoKlass Metaspace，但是也其实可以存klass的内容。
					
					Klass Metaspace和NoKlass Mestaspace都是所有classloader共享的，所以类加载器们要分配内存，但是每个类加载器都有一个SpaceManager，来管理属于这个类加载的内存小块。如果Klass Metaspace用完了，那就会OOM了，
				不过一般情况下不会，NoKlass Mestaspace是由一块块内存慢慢组合起来的，在没有达到限制条件的情况下，会不断加长这条链，让它可以持续工作。
			元空间的特点：
				充分利用了Java语言规范中的好处：类及相关的元数据的生命周期与类加载器的一致。
				每个加载器有专门的存储空间
				只进行线性分配
				不会单独回收某个类
				省掉了GC扫描及压缩的时间
				元空间里的对象的位置是固定的
				如果GC发现某个类加载器不再存活了，会把相关的空间整个回收掉
			元空间的内存分配模型：
				绝大多数的类元数据的空间都从本地内存中分配
				用来描述类元数据的类(klasses)也被删除了
				分元数据分配了多个虚拟内存空间
				给每个类加载器分配一个内存块的列表。块的大小取决于类加载器的类型； sun/反射/代理对应的类加载器的块会小一些
				归还内存块，释放内存块列表
				一旦元空间的数据被清空了，虚拟内存的空间会被回收掉
				减少碎片的策略
https://cloud.tencent.com/developer/article/1492048
https://cloud.tencent.com/developer/article/1492048
https://cloud.tencent.com/developer/article/1492048
https://cloud.tencent.com/developer/article/1492048
https://cloud.tencent.com/developer/article/1492048
	5、jvm 中一次完整的 GC 流程（从 ygc 到 fgc ）是怎样的，重点讲讲对象如何晋升到老年代，几种主要的 jvm 参数等
		Java 8 整个的JVM堆内存之中实际上将内存分为了三块：
			年轻代：新对象和没达到一定年龄的对象都在年轻代；
			老年代：被长时间使用的对象，老年代的内存空间应该要比年轻代更大；
			元空间：像一些方法中的操作临时对象等，直接使用物理内存；
		对于整个的GC流程里面，那么最需要处理的就是年轻代与老年代的内存清理操作，而元空间（永久代）都不在GC范围内；
		内存分配策略流程如下：
			a.当现在有一个新的对象产生，那么对象一定需要内存空间，于是现在就需要为该对象进行内存空间的申请；
				大对象直接进入老年代 ：
					JVM提供了一个对象大小阈值参数(-XX:PretenureSizeThreshold，默认值为0，代表不管多大都是先在Eden中分配内存)，大于参数设置的阈值值的对象直接在老年代分配，这样可以避免对象在Eden及两个Survivor直接发生大内存复制
			b.首先会判断伊甸园区是否有内存空间，如果此时有内存空间，则直接将新对象保存在伊甸园区；
			c.但是如果此时伊甸园区的内存空间不足，那么会自动执行一个 MinorGC 操作，将伊甸园区的无用内存空间进行清理，清理之后会继续判断伊甸园区的内存空间是否充足？如果内存空间充足，则将新的对象直接在伊甸园区进行空间分配；
				空间分配担保：
					当进行Young GC之前，JVM需要预估老年代是否能够容纳 Young GC 后新生代晋升到老年代的存活对象，以确定是否需要提前触发GC回收老年代空间
					基于空间分配担保策略来计算：
						continueSize：老年代最大可用连续空间
						continueSize 是否大于新生代所有对象总空间，yes 则执行 Young GC
						no continueSize 是否大于平均晋升到老年代对象的平均大小，no 则执行 Full GC
						yes 则执行 Young GC
						继续判断 continueSize 是否大于需晋升到老年代的对象大小， no 则担保失败，接着执行 Full GC
						YES 则担保成功，空间分配担保流程结束
			d.如果执行了 Minor GC 之后发现伊甸园区的内存依然不足，那么这个时候会进行存活区判断，如果存活区有剩余空间，则将伊甸园区的部分活跃对象保存在存活区，那么随后继续判断伊甸园区的内存空间是否充足，如果充足，则在伊甸园区进行新对象的空间分配；
				注意：当前的 Survivor 区满时，此区的存活且不满足晋升到老年代条件的对象将被复制到另外一个 Survivor 区。对象每经历一次复制，年龄加1，达到晋升年龄阈值后，转移到老年代
			e.如果此时存活区也已经没有内存空间了，则继续判断老年区，如果此时老年区空间充足，则将存活区中的活跃对象保存到老年代，而后存活区就会存现有空余空间，随后伊甸园区将活跃对象保存在存活区之中，而后在伊甸园区里为新对象开辟空间；
			f.如果这个时候老年代也满了，那么这个时候将产生 Major GC（Full GC），进行老年代的内存清理。
			g.如果老年代执行了 Full GC 之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。
			动态年龄判定：
				新生代对象的年龄可能没达到阈值(MaxTenuringThreshold参数指定)就晋升老年代，如果Young GC之后，新生代存活对象达到相同年龄所有对象大小的总和大于任一Survivor空间(S0 或 S1总空间)的一半，
				此时S0或者S1区即将容纳不了存活的新生代对象，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄
				另外，如果Young GC后S0或S1区不足以容纳：未达到晋升老年代条件的新生代存活对象，会导致这些存活对象直接进入老年代，需要尽量避免
		Minor Gc 触发条件：
			如上所述。
			另外：Minor Gc （又叫 Young GC） 每次都会引起全线停顿(Stop-The-World)，暂停所有的应用线程，停顿时间相对老年代GC的造成的停顿，几乎可以忽略不计
		Major Gc 触发条件：
			Major GC，只清理老年代空间的GC事件，只有CMS的并发收集是这个模式 Full GC，清理整个堆的GC事件，包括新生代、老年代、元空间等，Mixed GC，清理整个新生代以及部分老年代的GC，只有G1有这个模式。


			https://juejin.im/post/5b6b986c6fb9a04fd1603f4a
	6、GC日志分析
		GC日志是一个很重要的工具，它准确记录了每一次的GC的执行时间和执行结果，通过分析GC日志可以调优堆设置和GC设置，或者改进应用程序的对象分配模式，开启的JVM启动参数如下：
			Young GC：
				GC开始时间 +0800 表示中国所在东8区    GC开始时间相对JVM开始启动时间间隔秒数  GC 表示 Young GC+触发原因 
				--2019-12-20T17:49:34.558+0800:       1.332:                              [GC (Allocation Failure)  
				垃圾收集器名称  垃圾收集前、后新生代使用量/新生代总空间大小    垃圾收集前、后整个堆的内存使用量/堆总空间大小  GC 事件持续时间
				--[PSYoungGen: 65536K->5886K(76288K)]                    65536K->5894K(251392K),                    0.0071360 secs] 
				GC线程消耗CPU的时间/操作系统调用和系统等待事件锁消耗的时间/应用程序暂停的时间
				--[Times: user=0.00 sys=0.00, real=0.01 secs] 
			Young GC：
				--2019-12-20T17:49:35.425+0800: 2.200: [Full GC (Metadata GC Threshold) [PSYoungGen: 5762K->0K(141824K)] 
				--[ParOldGen: 104K->5727K(77824K)] 5866K->5727K(219648K), [Metaspace: 21122K->21121K(1069056K)], 0.0217453 secs] [Times: user=0.06 sys=0.03, real=0.02 secs]
		免费的GC日志图形分析工具：GCViewer 和 gceasy 
	7、Java 垃圾回收算法
		Stop The World：
			GC过程中分析对象引用关系，为了保证分析结果的准确性，需要通过停顿所有Java执行线程，保证引用关系不再动态变化，该停顿事件称为Stop The World(STW)
		Safepoint：
			代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要GC，线程可以在这个位置暂停。HotSpot采用主动中断的方式，让执行线程在运行期轮询是否需要暂停的标志，若需要则中断挂起
		一、标记-清除算法（标记阶段+清除阶段）:
			碎片化，造成内存不连续
		二、复制算法（将可用内存分为对象面和空闲面——>对象在对象面上创建——>存活的对象被从对象面 复制到空闲面——>将对象面所有对象内存清除）:
			解决碎片化问题 顺序分配内存，简单高效 适用于对象存活率低的场景,不适合 对象存活率高的场景，会进行大量复制操作 可用空间减半
		三、标记-整理算法:
			标记阶段： 从根集合进行扫描，对存活的对象进行标记
			整理阶段： 移动所有存活的对象，且按照内存地址次序依次排列，然后将末端内存地址以后的内存全部回收
			优点：
				避免内存的不连续行
				不用设置两块内存互换
				适用于存活率高的场景
		四、分代收集算法(垃圾回收算法的组合拳):
			按照对象生命周期的不同划分区域以采用不同的垃圾回收算法。能够明显提高提高JVM的回收效率。
			分代收集算法将内存区域分为年轻代、老年代（JDK8开始取消永久代，使用元空间代替）并使用不同的GC进行垃圾回收。
			年轻代（占总堆内存的三分之一）：
				将内存区域进一步划分为 Eden 区，和2个 Survivor 区
				Eden GC 时，将存活对象复制到 Survivor1中，Survivor1 GC 时将存活对象复制到 Survivor2 中。
				采用 Minor GC（复制算法）
				尽可能快速地收集掉那么些生命周期短的对象
				年轻代对象可以晋升到老年代
			老年代（占总堆内存的三分之二）：
				存放生命周期较长的对象
				使用 Full GC（标记清理算法或者标记整理算法）
				老年代GC时，会触发对整个堆内存的垃圾回收。
			年轻代对象如何晋升到老年代：
				（1）经历一定 Minor GC 次数 依然存活的对象
				（2）Survivo 区中存放不下的对象
				（3）新生成的大对象 (-XX:+PretenuerSizeThreshold)
			触发Full GC的条件：
				（1）老年代空间不足
				（2）永久代空间不足（jkd 8 之前）
				（3）CMC GC 时 出现 promotion failed, concurrent mode failure
				（4）Minor GC 晋升到老年代的平均大小大于老年代的剩余空间
				（5）调用 System.gc()[通知JVM进行垃圾回收，但要注意，虽然发出了通知，JVM不一定会立刻执行，也就是说这句是无法确保此时JVM一定会进行垃圾回收的]
				（6）使用 RMI 来进行 RPC 或管理的 JDK 应用，每小时执行1次 Full GC
		五、finalize()方法：
			JavaGC时 会对对象做两次标记， 第一次标记， 判断对象是否要执行finalize()方法，如果需要执行，就将对象放置于F-Queue队列中，并在稍后由虚拟机创建的一个低优先级的线程触发执行 该对象的finalize()方法。
			该方法执行 随时可能被终止，作用是给予对象最后一个重生的机会。
	8、你知道哪几种垃圾收集器，各自的优缺点，重点讲下 cms，g1
		一、CMS(Concurrent Mark and Sweep 并发-标记-清除)：
			是一款基于并发、使用标记清除算法的垃圾回收算法，只针对老年代进行垃圾回收，而Full GC指的是整个堆的GC事件，包括新生代、老年代、元空间等，两者有所区分。CMS收集器工作时，尽可能让GC线程和用户线程并发执行，以达到降低STW时间的目的。
			通过以下命令行参数，启用CMS垃圾收集器：-XX:+UseConcMarkSweepGC
			一、可以分为7个阶段：
				1、初始标记——2、并发标记——3、并发预清理——4、并发可取消预清理——5、最终标记——6、并发清除——7、并发重置      1、5：STW；2、3、4、6、7：GC线程与应用线程并发执行
				阶段 1: 初始标记(Initial Mark)
					此阶段的目标是标记老年代中所有存活的对象, 包括 GC Root 的直接引用, 以及由新生代中存活对象所引用的对象，触发第一次STW事件
					这个过程是支持多线程的（JDK7之前单线程，JDK8之后并行，可通过参数 CMSParallelInitialMarkEnabled 调整）
				阶段 2: 并发标记(Concurrent Mark)
					此阶段GC线程和应用线程并发执行，遍历阶段1初始标记出来的存活对象，然后继续递归标记这些对象可达的对象
				阶段 3: 并发预清理(Concurrent Preclean)
					此阶段GC线程和应用线程也是并发执行，因为阶段2是与应用线程并发执行，可能有些引用关系已经发生改变。
					通过卡片标记 (Card Marking)，提前把老年代空间逻辑划分为相等大小的区域(Card)，如果引用关系发生改变，JVM会将发生改变的区域标记位“脏区”(Dirty Card)，然后在本阶段，这些脏区会被找出来，刷新引用关系，清除“脏区”标记
				阶段 4: 并发可取消的预清理(Concurrent Abortable Preclean)
					此阶段也不停止应用线程. 本阶段尝试在 STW 的 最终标记阶段(Final Remark)之前尽可能地多做一些工作，以减少应用暂停时间
					在该阶段不断循环处理：标记老年代的可达对象、扫描处理 Dirty Card 区域中的对象，循环的终止条件有：
					a.达到循环次数
					b.达到循环执行时间阈值
					c.新生代内存使用率达到阈值
				阶段 5: 最终标记(Final Remark)
					这是 GC 事件中第二次(也是最后一次)STW阶段，目标是完成老年代中所有存活对象的标记。在此阶段执行： 
						a.遍历新生代对象，重新标记
						b.根据 GC Roots，重新标记
						c.遍历老年代的 Dirty Card，重新标记
				阶段 6: 并发清除(Concurrent Sweep)
					此阶段与应用程序并发执行，不需要STW停顿，根据标记结果清除垃圾对象
				阶段 7: 并发重置(Concurrent Reset)
					此阶段与应用程序并发执行，重置CMS算法相关的内部数据, 为下一次GC循环做准备
			二、CMS常见问题
				最终标记阶段停顿时间过长问题：
					CMS的GC停顿时间约80%都在最终标记阶段(Final Remark)，若该阶段停顿时间过长，常见原因是新生代对老年代的无效引用，在上一阶段的并发可取消预清理阶段中，执行阈值时间内未完成循环，来不及触发Young GC，清理这些无效引用
					通过添加参数：-XX:+CMSScavengeBeforeRemark。在执行最终操作之前先触发Young GC，从而减少新生代对老年代的无效引用，降低最终标记阶段的停顿，但如果在上个阶段(并发可取消的预清理)已触发Young GC，也会重复触发Young GC
				并发模式失败(concurrent mode failure)：
					当CMS在执行回收时，新生代发生垃圾回收，同时老年代又没有足够的空间容纳晋升的对象时，CMS 垃圾回收就会退化成单线程的Full GC。所有的应用线程都会被暂停，老年代中所有的无效对象都被回收。
				晋升失败(promotion failed)：
					当新生代发生垃圾回收，老年代有足够的空间可以容纳晋升的对象，但是由于空闲空间的碎片化，导致晋升失败，此时会触发单线程且带压缩动作的 Full GC
				
				并发模式失败和晋升失败都会导致长时间的停顿，常见解决思路如下：
					降低触发CMS GC的阈值，即参数-XX:CMSInitiatingOccupancyFraction的值，让CMS GC尽早执行，以保证有足够的空间
					增加CMS线程数，即参数-XX:ConcGCThreads
					增大老年代空间
					让对象尽量在新生代回收，避免进入老年代
				内存碎片问题：
		二、G1原理及调优：
			G1(Garbage-First）是一款面向服务器的垃圾收集器，支持新生代和老年代空间的垃圾收集，主要针对配备多核处理器及大容量内存的机器，G1最主要的设计目标是: 实现可预期及可配置的STW停顿时间。
			G1堆空间划分：
				Region：
					为实现大内存空间的低停顿时间的回收，将划分为多个大小相等的 Region。每个小堆区都可能是 Eden 区，Survivor 区或者 Old 区，但是在同一时刻只能属于某个代。
					在逻辑上, 所有的 Eden 区和 Survivor 区合起来就是新生代，所有的 Old 区合起来就是老年代，且新生代和老年代各自的内存 Region 区域由 G1 自动控制，不断变动。
				巨型对象：
					当对象大小超过Region的一半，则认为是巨型对象(Humongous Object)，直接被分配到老年代的巨型对象区(Humongous regions)，这些巨型区域是一个连续的区域集，每一个Region中最多有一个巨型对象，巨型对象可以占多个Region。
			G1 把堆内存划分成一个个 Region 的意义在于：
				每次GC不必都去处理整个堆空间，而是每次只处理一部分Region，实现大容量内存的GC。
				通过计算每个 Region 的回收价值，包括回收所需时间、可回收空间，在有限时间内尽可能回收更多的垃圾对象，把垃圾回收造成的停顿时间控制在预期配置的时间范围内，这也是G1名称的由来: garbage-first。
			G1 工作模式：
				针对新生代和老年代，G1提供2种GC模式，Young GC 和 Mixed GC，两种会导致 Stop The World。
				Young GC：
					当新生代的空间不足时，G1触发 Young GC 回收新生代空间。Young GC 主要是对 Eden 区进行GC，它在 Eden 空间耗尽时触发，基于分代回收思想和复制算法，每次 Young GC 都会选定所有新生代的 Region，
					同时计算下次 Young GC 所需的 Eden 区和 Survivor 区的空间，动态调整新生代所占 Region 个数来控制 Young GC 开销。
				Mixed GC：
					当老年代空间达到阈值会触发 Mixed GC，选定所有新生代里的 Region，根据全局并发标记阶段(下面介绍到)统计得出收集收益高的若干老年代 Region。在用户指定的开销目标范围内，
					尽可能选择收益高的老年代 Region 进行 GC，通过选择哪些老年代 Region 和选择多少 Region 来控制 Mixed GC 开销。
			全局并发标记：
				主要是为 Mixed GC 计算找出回收收益较高的 Region 区域，具体分为5个阶段：
				阶段 1: 初始标记(Initial Mark)——STW
					并发地进行标记从 GC Root 开始直接可达的对象（原生栈对象、全局对象、JNI 对象），当达到触发条件时，G1 并不会立即发起并发标记周期，而是等待下一次新生代收集，
					利用新生代收集的 STW 时间段，完成初始标记，这种方式称为借道（Piggybacking）
				阶段 2: 根区域扫描（Root Region Scan）
					在初始标记暂停结束后，新生代收集也完成的对象复制到 Survivor 的工作，应用线程开始活跃起来；
					此时为了保证标记算法的正确性，所有新复制到 Survivor 分区的对象，需要找出哪些对象存在对老年代对象的引用，把这些对象标记成根(Root)；
					这个过程称为根分区扫描（Root Region Scanning），同时扫描的 Suvivor 分区也被称为根分区（Root Region）；
					根分区扫描必须在下一次新生代垃圾收集启动前完成（接下来并发标记的过程中，可能会被若干次新生代垃圾收集打断），因为每次 GC 会产生新的存活对象集合
				阶段 3: 并发标记（Concurrent Marking）
					标记线程与应用程序线程并行执行，标记各个堆中 Region 的存活对象信息，这个步骤可能被新的 Young GC 打断
					所有的标记任务必须在堆满前就完成扫描，如果并发标记耗时很长，那么有可能在并发标记过程中，又经历了几次新生代收集
				阶段 4: 再次标记(Remark) ——STW
					以完成标记过程短暂地停止应用线程, 标记在并发标记阶段发生变化的对象，和所有未被标记的存活对象，同时完成存活数据计算
				阶段 5: 清理(Cleanup) 
					为即将到来的转移阶段做准备, 此阶段也为下一次标记执行所有必需的整理计算工作：
						整理更新每个 Region 各自的 RSet(remember set，HashMap结构，记录有哪些老年代对象指向本 Region，key 为指向本 Region的 对象的引用，value 为指向本 Region 的具体 Card 区域，通过 RSet 可以确定 Region 中对象存活信息，避免全堆扫描)；
						回收不包含存活对象的 Region；
						统计计算回收收益高（基于释放空间和暂停目标）的老年代分区集合；
			G1调优注意点：
				Full GC问题：
					G1的正常处理流程中没有Full GC，只有在垃圾回收处理不过来(或者主动触发)时才会出现， G1的Full GC就是单线程执行的Serial old gc，会导致非常长的STW，是调优的重点，需要尽量避免Full GC。
					常见原因如下：
						程序主动执行System.gc()
						全局并发标记期间老年代空间被填满（并发模式失败）
						Mixed GC期间老年代空间被填满（晋升失败）
						Young GC时Survivor空间和老年代没有足够空间容纳存活对象
					类似CMS，常见的解决是：
						增大-XX:ConcGCThreads=n 选项增加并发标记线程的数量，或者STW期间并行线程的数量：-XX:ParallelGCThreads=n
						减小-XX:InitiatingHeapOccupancyPercent 提前启动标记周期
						增大预留内存 -XX:G1ReservePercent=n ，默认值是10，代表使用10%的堆内存为预留内存，当Survivor区域没有足够空间容纳新晋升对象时会尝试使用预留内存
				巨型对象分配：
					巨型对象区中的每个 Region 中包含一个巨型对象，剩余空间不再利用，导致空间碎片化，当G1没有合适空间分配巨型对象时，G1会启动串行 Full GC 来释放空间。
					可以通过增加 -XX:G1HeapRegionSize 来增大 Region 大小，这样一来，相当一部分的巨型对象就不再是巨型对象了，而是采用普通的分配方式。
				不要设置 Young 区的大小：
					原因是为了尽量满足目标停顿时间，逻辑上的 Young 区会进行动态调整。如果设置了大小，则会覆盖掉并且会禁用掉对停顿时间的控制。
				平均响应时间设置：
					使用应用的平均响应时间作为参考来设置 MaxGCPauseMillis，JVM会尽量去满足该条件，可能是90%的请求或者更多的响应时间在这之内， 但是并不代表是所有的请求都能满足，平均响应时间设置过小会导致频繁GC。
		三、调优方法与思路：
			GC优化的核心思路在于：
				尽可能让对象在新生代中分配和回收，尽量避免过多对象进入老年代，导致对老年代频繁进行垃圾回收，同时给系统足够的内存减少新生代垃圾回收次数，进行系统分析和优化也是围绕着这个思路展开。
				也就是说将转移到老年代的对象数量降低到最小；减少 full GC 的执行时间；
			需要做的事情有：
				减少使用全局变量和大对象；
				调整新生代的大小到最合适；
				设置老年代的大小为最合适；
				选择合适的GC收集器；
			分析系统的运行状况：
				系统每秒请求数、每个请求创建多少对象，占用多少内存
				Young GC触发频率、对象进入老年代的速率
				老年代占用内存、Full GC触发频率、Full GC触发的原因、长时间Full GC的原因
			进行监控和调优的一般步骤为：
				1，监控GC的状态
					使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化；
				2，分析结果，判断是否需要优化
					如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过 1-3 秒，或者频繁GC，则必须优化；
					如果满足下面的指标，则一般不需要进行GC：Minor GC执行时间不到50ms；Minor GC执行不频繁，约10秒一次；Full GC执行时间不到1s；Full GC执行频率不算频繁，不低于10分钟1次；
				3、调整GC类型和内存分配
					如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行对比，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择；
				4、不断的分析和调整并找到最合适的参数——>全面应用参数
			常用工具如下：
				一、jstat：jvm 自带命令行工具，可用于统计内存分配速率、GC次数，GC耗时，常用命令格式：
					jstat -gc <pid> <统计间隔时间>  <统计次数>      例如： jstat -gc 32683 1000 10 ，统计pid= 32683 的进程，每秒统计1次，统计10次
					如：
						s0 区容量/s1 区容量/s0 区已用内存/s1 区已用内存  之后是Eden、老年代、元空间的容量及其已用内存个  再之后是YGC总次数、YGC总耗时、FGC总次数、FGC总耗时、GC总耗时
						S0C S1C S0U S1U EC EU OC OU MC MU YGC YGCT FGC FGCT GCT
				二、jmap：jvm 自带命令行工具，可用于了解系统运行时的对象分布，常用命令格式：
					// 命令行输出类名、类数量数量，类占用内存大小，
					// 按照类占用内存大小降序排列
					jmap -histo <pid>
					// 生成堆内存转储快照，在当前目录下导出 dump.hrpof 的二进制文件，
					// 可以用 eclipse 的 MAT 图形化工具分析
					jmap -dump:live,format=b,file=dump.hprof <pid>
				三、jinfo 命令格式：
					jinfo <pid>
					用来查看正在运行的 Java 应用程序的扩展参数，包括 Java System 属性和 JVM 命令行参数
			其他GC工具：
				监控告警系统：Zabbix、Prometheus、Open-Falcon
				jdk 自动实时内存监控工具：VisualVM
				堆外内存监控： Java VisualVM 安装 Buffer Pools 插件、google perf 工具、Java NMT(Native Memory Tracking)工具
				GC日志分析：GCViewer、gceasy
				GC参数检查和优化：xxfox.perfma.com/
			JVM参数解析及调优：
				比如以下参数示例：-Xmx4g –Xms4g –Xmn1200m –Xss512k -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:PermSize=100m -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15
				-XX:PermSize=100m -XX:MaxPermSize=256m 在Java 8 中已失效，会有错误警告。
				参数解析：
					-Xmx4g：可调优，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。
						堆内存最大值为4GB。
					-Xms4g：可调优，初始化堆内存大小，默认为物理内存的1/64(小于1GB)。
						初始化堆内存大小为4GB。
					-Xmn1200m：
						设置年轻代大小为1200MB。增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
					-Xss512k：
						设置每个线程的堆栈大小。JDK5.0 以后每个线程堆栈大小为1MB，以前每个线程堆栈大小为256K。应根据应用线程所需内存大小进行调整。
						在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000 左右。
					-XX:NewRatio=4：
						设置年轻代（包括 Eden 和两个 Survivor 区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
					-XX:SurvivorRatio=8：
						设置年轻代中 Eden 区与 Survivor 区的大小比值。设置为8，则两个 Survivor 区与一个 Eden 区的比值为2:8，一个 Survivor 区占整个年轻代的1/10
					-XX:MaxTenuringThreshold=15：
						设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过 Survivor 区，直接进入年老代。对于年老代比较多的应用，可以提高效率。
						如果将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
					-XX:MaxDirectMemorySize=1G：可调优
						直接内存。报java.lang.OutOfMemoryError: Direct buffer memory 异常可以上调这个值。
					-XX:+DisableExplicitGC：
						禁止运行期显式地调用System.gc()来触发fulll GC。
					-XX:CMSInitiatingOccupancyFraction=60：
						老年代内存回收阈值，默认值为68。
					-XX:ConcGCThreads=4：
						CMS垃圾回收器并行线程线，推荐值为CPU核心数。
					-XX:ParallelGCThreads=8：
						新生代并行收集器的线程数。
			参数：
				堆参数：
					-Xms、-Xmx、-Xmn、-XX:SurvivorRatio、-XX:NewRatio
				回收器参数：
					-XX:+UseSerialGC 串行、Y O 都串行化，使用复制算法回收，逻辑简单搞笑，无线程切换开销
					-XX:+UseParallelGC 并行，Y 使用 Parallel Scavenge 回收算法，会产生多个并行回收线程，通过-XX:ParallelGCThreads=n 参数指定线程数，默认是CPU 核数；O 依然单线程
					-XX:+UseParalleOldGC 并行，Y O 都是用多线程收集
					-XX:+UseConcMarpSweepGC CMS短暂并发的收集。Y 可使用普通的或 Parallel 垃圾收集算法，由参数-XX:+UseParNewGC 来控制；O 只能使用CMS
					-XX:+UseG1GC 并行、并发、增量式压缩短暂停顿的垃圾收集器。不区分 Y O；优先收集存活对象少的 Region，因此叫 Garbage First
				常用组合：
					-XX:+UseSerialGC： Y Serial O Serial
					-XX:+UseParallelGC 和 -XX:+UseParalleOldGC：Y Parallel Scavenge O Parallel Old/Serial
					-XX:+UseParNewGC 和 -XX:+UseConcMarpSweepGC：Y Seril/Parallel O CMS
					-XX:+UseG1GC：G1
		四、GC优化案例
			数据分析平台系统频繁 Full GC：
				平台主要对用户在APP中行为进行定时分析统计，并支持报表导出，使用CMS GC算法。数据分析师在使用中发现系统页面打开经常卡顿，通过 jstat 命令发现系统每次 Young GC 后大约有10%的存活对象进入老年代。
				原来是因为 Survivor 区空间设置过小，每次 Young GC 后存活对象在 Survivor 区域放不下，提前进入老年代，通过调大 Survivor区，使得 Survivor 区可以容纳 Young GC 后存活对象，对象在 Survivor 区经历多次
				Young GC 达到年龄阈值才进入老年代，调整之后每次 Young GC 后进入老年代的存活对象稳定运行时仅几百 Kb，Full GC 频率大大降低。
			业务对接网关OOM：
				网关主要消费 Kafka 数据，进行数据处理计算然后转发到另外的 Kafka 队列，系统运行几个小时候出现OOM，重启系统几个小时之后又 OOM，通过 jmap 导出堆内存，
				在 eclipse MAT 工具分析才找出原因：代码中将某个业务 Kafka 的 topic 数据进行日志异步打印，该业务数据量较大，大量对象堆积在内存中等待被打印，导致OOM
			账号权限管理系统频繁长时间 Full GC：
				系统对外提供各种账号鉴权服务，使用时发现系统经常服务不可用，通过 Zabbix 的监控平台监控发现系统频繁发生长时间 Full GC，且触发时老年代的堆内存通常并没有占满，发现原来是业务代码中调用了 System.gc()。
		https://juejin.im/post/5b6b986c6fb9a04fd1603f4a
	9、新生代和老生代的内存回收策略
		新生代垃圾回收：
			能与 CMS 搭配使用的新生代垃圾收集器有 Serial 收集器和 ParNew 收集器。这2个收集器都采用标记复制算法，都会触发STW事件，停止所有的应用线程。不同之处在于，Serial 是单线程执行，ParNew 是多线程执行。
		老年代垃圾回收：
			见上述分析
			G1 和 CMS
	10、Eden 和 Survivor 的比例分配等
		eden 和survivor 区比例为什么是8:1：
			因为经过统计，每次 Young GC 会有 90% 的对象被回收，所以要预留空间去保存剩下的10%
	11、深入分析 Classloader，双亲委派机制
		Classloader：
			static class AppClassLoader extends URLClassLoader （Launcher 内部静态类）
			static class ExtClassLoader extends URLClassLoader （Launcher 内部静态类）
			public class URLClassLoader extends SecureClassLoader
			public class SecureClassLoader extends ClassLoader
			public abstract class ClassLoader
		双亲委派机制：
			如果一个类加载器收到了加载某个类的请求，则该类加载器并不会去加载该类，而是把这个请求委派给父类加载器，每一个层次的类加载器都是如此，因此所有的类加载请求最终都会传送到顶端的启动类加载器；
			只有当父类加载器在其搜索范围内无法找到所需的类，并将该结果反馈给子类加载器，子类加载器会尝试去自己加载。
			好处：
					如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，
				Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
					其次是考虑到安全因素。假设通过网络传递一个名为 java.lang.Integer 的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心 Java API 发现这个名字的类，发现该类已被加载，
				并不会重新加载网络传递的过来的 java.lang.Integer，而直接返回已加载过的 Integer.class，这样便可以防止核心API库被随意篡改。
		如何破坏双亲委派模型：
			在实际的应用中双亲委派解决了 java 基础类统一加载的问题，但是却着实存在着一定的缺席。 jdk 中的基础类作为用户典型的 api 被调用，但是也存在被 api 调用用户的代码的情况，典型的如 SPI 代码。
			SPI 的全名为 Service Provider Interface，主要是应用于厂商自定义组件或插件中。
			java SPI 机制的思想：
				我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块、xml 解析模块、jdbc 模块等方案。
				面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。
				为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。Java SPI 就是提供这样的一个机制：为某个接口寻找服务实现的机制。
				有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
				所以 jdk 开发人员就引入了线程上下文类加载器（Thread Context ClassLoader），这类类加载器可以通过 java.lang.Thread 类的 setContextClassLoader 方法进行设置，也就是拿到上下文加载器（用户自定义加载器）来
				加载指定的类。
				如：java.sql.DriverManager 中有静态代码块 static {loadInitialDrivers(); ...}
				private static void loadInitialDrivers() {
			        String drivers;
			        try {
			        	// 先读取系统属性
			            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
			                public String run() {
			                    return System.getProperty("jdbc.drivers");
			                }
			            });
			        } catch (Exception ex) {
			            drivers = null;
			        }
			        // 通过SPI加载驱动类
			        AccessController.doPrivileged(new PrivilegedAction<Void>() {
			            public Void run() {

			                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
			                Iterator<Driver> driversIterator = loadedDrivers.iterator();
			                try{
			                    while(driversIterator.hasNext()) {
			                        driversIterator.next();
			                    }
			                } catch(Throwable t) {
			                }
			                return null;
			            }
			        });
			        println("DriverManager.initialize: jdbc.drivers = " + drivers);
			        if (drivers == null || drivers.equals("")) {
			            return;
			        }
			        // 继续加载系统属性中的驱动类
			        String[] driversList = drivers.split(":");
			        println("number of Drivers:" + driversList.length);
			        for (String aDriver : driversList) {
			            try {
			                println("DriverManager.Initialize: loading " + aDriver);
			                Class.forName(aDriver, true,
			                        ClassLoader.getSystemClassLoader());
			            } catch (Exception ex) {
			                println("DriverManager.Initialize: load failed: " + ex);
			            }
			        }
			    }
			    注意driversIterator.next() 最终就是调用 Class.forName(DriverName, false, loader) 方法。
				对于自己加载不了的类怎么办，直接用线程上下类加载器加载，通过 ClassLoader cl = Thread.currentThread().getContextClassLoader();
				这条语句获取本地线程然后实现上下类加载。所以这个地方 Bootstrap Classloader 加载器拿到了 Application ClassLoader 加载器应该加载的类，就打破了双亲委派模型。
		JDBC Tomcat 为什么要破坏双亲委派机制：

		JAVA热部署实现：
				热部署是在不重启 Java 虚拟机的前提下，能自动侦测到 class 文件的变化，更新运行时 class 的行为。Java 类是通过 Java 虚拟机加载的，某个类的 class 文件在被 classloader 加载后，
			会生成对应的 Class 对象，之后就可以创建该类的实例。默认的虚拟机行为只会在启动时加载类，如果后期有一个类需要更新的话，单纯替换编译的 class 文件，Java 虚拟机是不会更新正在运行的 class。
			如果要实现热部署，最根本的方式是修改虚拟机的源代码，改变 classloader 的加载行为，使虚拟机能监听 class 文件的更新，重新加载 class 文件，这样的行为破坏性很大。
				另一种友好的方法是创建自己的 classloader 来加载需要监听的 class，这样就能控制类加载的时机，从而实现热部署。
			热部署步骤：
				销毁自定义classloader(被该加载器加载的class也会自动卸载)；
				更新class；
				使用新的ClassLoader去加载class；
			JVM中的Class只有满足以下三个条件，才能被GC回收，也就是该Class被卸载（unload）：
				该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例；
				加载该类的ClassLoader已经被GC；
				该类的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法；
		自定义类加载器：
			要创建用户自己的类加载器，只需要继承java.lang.ClassLoader类，然后覆盖它的findClass(String name)方法即可，即指明如何获取类的字节码流。
			如果要符合双亲委派规范，则重写findClass方法（用户自定义类加载逻辑）；要破坏的话，重写loadClass方法(双亲委派的具体逻辑实现)。
	12、JVM 的编译优化
		编译期优化（早期优化）
			编译期优化主要为语法糖，用来实现Java的各种新的语法特性，比如泛型，变长参数，自动装箱/拆箱。
			Java泛型只在编译期存在，编译完成后的字节码中会替换为原生类型。故称Java泛型为伪泛型。
			if语句中使用常量。比如if(false) {},这个语句块不会被编译到字节码中.这个过程在编译时的控制流分析中完成。
		运行时优化（晚期优化）
			Hotspot采用解释器与编译器并存的构架
			公共字表达式消除
				如果一个表达式E已经被计算过了，并且从先前的计算到现在E中所有变量的值都没有发生变化，那么E的这次出现就称为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替E就可以了。
			数组边界检查消除
				数组下标示一个常量，如foo3，只要在编译器根据数据流分析来确定foo.length的值，并判断下标“3”没有越界，执行的时候就无须判断了。
				类似还有自动装箱消除、安全点消除、消除反射
			方法内联
			逃逸分析
	13、对 Java 内存模型的理解，以及其在并发中的应用
		主要针对指令重排序、synchronized、final、volatile
	14、指令重排序，happen-before
		指令重排序是编译器或处理器为了提高兴许性能而做得优化。
		为什么指令重排序可以提高性能：
			每一个指令都会包含多个步骤，每个步骤可能使用不同的硬件。因此，流水线技术产生了，它的原理是指令1还没有执行完，就可以开始执行指令2，而不用等到指令1执行结束之后再执行指令2，这样就大大提高了效率。
			a = b + c;
			d = e - f;
			先加载b、c（注意，即有可能先加载b，也有可能先加载c），但是在执行add(b,c)的时候，需要等待b、c装载结束才能继续执行，也就是增加了停顿，那么后面的指令也会依次有停顿,这降低了计算机的执行效率。
			为了减少这个停顿，我们可以先加载e和f,然后再去加载add(b,c),这样做对程序（串行）是没有影响的,但却减少了停顿。既然add(b,c)需要停顿，那还不如去做一些有意义的事情。
			分类：
				编译器优化重排（编译器优化）
					编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
				指令并行重排（处理器优化）
					现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性(即后一个执行的语句无需依赖前面执行的语句的结果)，处理器可以改变语句对应的机器指令的执行顺序。
				内存系统重排（处理器优化）
					由于处理器使用缓存和读写缓存冲区，这使得加载(load)和存储(store)操作看上去可能是在乱序执行，因为三级缓存的存在，导致内存与缓存的数据同步存在时间差。
			as-if-serial：无论如何重排序，程序执行的结果应该与代码顺序执行的结果一致（Java 编译器、运行时和处理器都会保证 Java 在单线程下遵循 as-if-serial 语义）
			重排序不会给单线程带来内存可见性的问题，多线程中程序交错执行时，就可能造成内存可见性问题。
		什么情况下不会进行指令重排序：
			写后读，写后写，读后写
		happens-before 关系的定义如下：
			1. 如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
			2. 两个操作之间存在 happens-before 关系，并不意味着 Java 平台的具体实现必须要按照 happens-before 关系指定的顺序来执行。如果重排序之后的执行结果，与按 happens-before 关系来执行的结果一致，那么JMM也允许这样的重排序。
		as-if-serial 语义保证单线程内重排序后的执行结果和程序代码本身应有的结果是一致的，happens-before 关系保证正确同步的多线程程序的执行结果不被重排序改变。
			如果操作A happens-before 操作B，那么操作A在内存上所做的操作对操作B都是可见的，不管它们在不在一个线程。
		天然的 happens-before 关系：
			监视器锁规则：对一个锁的解锁，happens-before 于随后对这个锁的加锁。
			volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile域的读。
			传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
			join 规则：如果线程A执行操作 ThreadB.join（）并成功返回，那么线程B中的任意操作 happens-before 于线程A从 ThreadB.join() 操作成功返回。
	15、volatile 的语义，内存栅栏等，它修饰的变量一定线程安全吗？与 synchronize 的区别
		volatile 两大作用：
			保证内存可见性、防止指令重拍（但不保证原子性，也就是它修饰的变量不一定是线程安全的）
		JVM内存模型：
			主内存和线程独立的工作内存
		Java 内存模型规定：
			对于多个线程共享的变量，存储在主内存当中，每个线程都有自己独立的工作内存（比如CPU的寄存器），线程只能访问自己的工作内存，不可以访问其它线程的工作内存。
			工作内存与主内存之间交互的协议，定义了8种原子操作：
				lock: 将主内存中的变量锁定，为一个线程所独占
				unclock: 将 lock 加的锁定解除，此时其它的线程可以有机会访问此变量
				read: 将主内存中的变量值读到工作内存当中
				load: 将 read 读取的值保存到工作内存中的变量副本中
				use: 将值传递给线程的代码执行引擎
				assign: 将执行引擎处理返回的值重新赋值给变量副本
				store: 将变量副本的值存储到主内存中
				write: 将 store 存储的值写入到主内存的共享变量当中
		指令重排导致单例模式失效：
			懒加载方式的双重判断单例模式：
			public class Singleton {
			    private static Singleton instance = null;
			    private Singleton() {
			    }

			    public static Singleton getInstance() {
			        if (instance == null) {
			            synchronized (Singleton.class) {
			                if (instance == null) {
			                    //非原子操作
			                    instance = new Singleton();
			                }
			            }
			        }
			        return instance;
			    }
			}
			instance = new Singleton() 可以抽象为下面几条JVM指令：
				memory = allocate();   // 1：分配对象的内存空间 
				ctorInstance(memory);  // 2：初始化对象 
				instance = memory;     // 3：设置 instance 指向刚分配的内存地址
			上面操作2 依赖于操作1，但是操作3 并不依赖于操作2，所以JVM是可以针对它们进行指令的优化重排序的，经过重排序后如下：
				memory = allocate();   // 1：分配对象的内存空间 
				instance = memory;     // 3：设置 instance 指向刚分配的内存地址
				ctorInstance(memory);  // 2：初始化对象 
			可以看到指令重排之后，instance 指向分配好的内存放在了前面，而这段内存的初始化被排在了后面。
			在线程A执行这段赋值语句，在初始化分配对象之前就已经将其赋值给 instance 引用，恰好另一个线程进入方法判断 instance 引用不为 null，然后就将其返回使用，导致出错。
		上述案例中使用关键字 volatile 对变量 instance 修饰后可避免可能出现的出错的问题。
		java 内存模型中讲到的 volatile 是基于 Memory Barrier 实现的，volatile 关键字通过提供“内存屏障”的方式来防止指令被重排序，为了实现 volatile 的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
		编译器和CPU能够重排序指令，保证最终相同的结果，尝试优化性能。插入一条 Memory Barrier 会告诉编译器和CPU：不管什么指令都不能和这条 Memory Barrier 指令重排序。
		JMM内存屏障插入策略：
			在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
			在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
			在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
			在每个 volatile 读操作的后面插入一个 LoadStore 屏障。
		Memory Barrier 所做的另外一件事是强制刷出各种 CPU cache，如一个 Write-Barrier（写入屏障）将刷出所有在 Barrier 之前写入 cache 的数据，因此，任何CPU上的线程都能读取到这些数据的最新版本。
		volatile 和 synchronized 区别：
			volatile 无法同时保证内存可见性和原子性。
			volatile 本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取；synchronized 则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
			作用域不同 volatile 仅能使用在变量级别；synchronized 则可以使用在变量、方法、和类级别的。
			volatile 不会造成线程的阻塞；synchronized 可能会造成线程的阻塞。volatile 标记的变量不会被编译器优化；synchronized 标记的变量可以被编译器优化。
	16、tomcat 结构，类加载器流程

	17、说一说你对环境变量 classpath 的理解？如果一个类不在 classpath 下，为什么会抛出 ClassNotFoundException 异常，如果在不改变这个类路径的前期下，怎样才能正确加载这个类？
		classpath 是 javac 编译器的一个环境变量。它的作用与 import、package 关键字有关。package 的所在位置，就是设置CLASSPATH。当编译器面对 import packag 这个语句时，它先会查找CLASSPATH所指定的目录，并检视子目录 java/util 是否存在，
		然后找出名称吻合的已编译文件（.class文件）。如果没有找到就会报错！
		NoClassDefFoundError 和 ClassNotfoundException
		NoClassDefFoundError：
			Java 虚拟机在编译时能找到合适的类，而在运行时不能找到合适的类导致的错误。
			有可能是类的静态初始化模块错误导致，当你的类执行一些静态初始化模块操作，如果初始化模块抛出异常，哪些依赖这个类的其他类会抛出NoClassDefFoundError的错误。
		ClassNotFoundException：
			编译时我们就知道错误发生，并且完全是由于环境的问题导致。
	18、说一下强引用、软引用、弱引用、虚引用以及他们之间和 gc 的关系
		强引用：
			如果一个对象具有强引用，那就类似于 必不可少 的物品，不会被垃圾回收器回收。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不回收这种对象。
			不过要注意的是，当method1运行完之后，object和objArr都已经不存在了，所以它们指向的对象都会被JVM回收。
			如果想中断强引用和某个对象之间的关联，可以显示地将引用赋值为 null，这样一来的话，JVM在合适的时间就会回收该对象。
			比如ArraryList类的 clear()方法中就是通过将引用赋值为 null 来实现清理工作的
		软引用：
			软引用是用来描述一些有用但并不是必需的对象，在 Java 中用 java.lang.ref.SoftReference 类来表示。
			对于软引用关联着的对象，只有在内存不足的时候JVM才会回收该对象。
			因此，这一点可以很好地用来解决OOM的问题，软引用非常适合于创建缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。
			redisson 的 cache 、guava 的 LocalCache、Histrix 的 HystrixTimer 都继承了 SoftReference。
			软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被JVM回收，这个软引用就会被加入到与之关联的引用队列中
			使用例子：
				// 注意：wrf这个引用也是强引用，它是指向SoftReference这个对象的，
				// 这里的软引用指的是指向new Obj()的引用，也就是SoftReference类中T
				SoftReference<String> wrf = new SoftReference<String>(new Obj());

				public class ImageData {
				    private String path;
				    private SoftReference<byte[]> dataRef;
				    public ImageData(String path) {
				        this.path = path;
				        dataRef = new SoftReference<byte[]>(new byte[0]);
				    }
				    private byte[] readImage() {
				        return new byte[1024 * 1024]; //省略了读取文件的操作
				    }
				    public byte[] getData() {
				        byte[] dataArray = dataRef.get();
				        if (dataArray == null || dataArray.length == 0) {
				            dataArray = readImage();
				            dataRef = new SoftReference<byte[]>(dataArray);
				        }
				        return dataArray;
				    }
				}
		弱引用：
			弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。
			在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。
			不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
			使用例子：
				String str=new String("abc");
				WeakReference abcWeakRef =new WeakReference(str);
				// 当垃圾回收器进行扫描回收时等价于：str = null; System.gc();
				str = null;
			弱引用最常见的用处是在集合类中，尤其在哈希表中。哈希表的接口允许使用任何 Java 对象作为键来使用。当一个键值对被放入到哈希表中之后，哈希表对象本身就有了对这些键和值对象的引用。
			如果这种引用是强引用的话，那么只要哈希表对象本身还存活，其中所包含的键和值对象是不会被回收的。如果某个存活时间很长的哈希表中包含的键值对很多，最终就有可能消耗掉 JVM 中全部的内存【ThreadLocal】。
			对于这种情况的解决办法就是使用弱引用来引用这些对象，这样哈希表中的键和值对象都能被垃圾回收。Java 中提供了 WeakHashMap 来满足这一常见需求。
			WeakHashMap：
				entry:
					private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> {
				        V value;
				        final int hash;
				        Entry<K,V> next;
				        Entry(Object key, V value,
				              ReferenceQueue<Object> queue,
				              int hash, Entry<K,V> next) {
				            super(key, queue);
				            this.value = value;
				            this.hash  = hash;
				            this.next  = next;
				        }
				        ...
				    }
				expungeStaleEntries()方法（剔除失效的Entry）:
					当key失效的时候gc会自动把对应的Entry添加到这个引用队列中；
					所有对map的操作都会直接或间接地调用到这个方法先移除失效的Entry，比如getTable()、size()、resize()；
					这个方法的目的就是遍历引用队列，并把其中保存的Entry从map中移除掉；
					从这里可以看到移除Entry的同时把value也一并置为null帮助gc清理元素，防御性编程。
			    总结：
					（1）WeakHashMap使用（数组 + 链表）存储结构；
					（2）WeakHashMap中的key是弱引用，gc的时候会被清除；
					（3）每次对map的操作都会剔除失效key对应的Entry；
					（4）使用String作为key时，一定要使用new String()这样的方式声明key，才会失效，其它的基本类型的包装类型是一样的；
					（5）WeakHashMap常用来作为缓存使用；
					当key是字符串时，通过new String()声明的变量才是弱引用，比如使用"6"这种声明方式会一直存在于常量池中，不会被清理，所以"6"这个元素会一直在map里面，其它的元素随着gc都会被清理掉。
		虚引用：
				在介绍幽灵引用之前，要先介绍Java提供的对象终止化机制（finalization）。在Object类里面有个finalize方法，其设计的初衷是在一个对象被真正回收之前，可以用来执行一些清理的工作。因为Java并没有提供类似C++的析构函数一样的机制，
			就通过 finalize方法来实现。但是问题在于垃圾回收器的运行时间是不固定的，所以这些清理工作的实际运行时间也是不能预知的。幽灵引用（phantom reference）可以解决这个问题。在创建幽灵引用PhantomReference的时候必须要指定一个引用队列。
			当一个对象的finalize方法已经被调用了之后，这个对象的幽灵引用会被加入到队列中。通过检查该队列里面的内容就知道一个对象是不是已经准备要被回收了。
				幽灵引用及其队列的使用情况并不多见，主要用来实现比较精细的内存使用控制，这对于移动设备来说是很有意义的。程序可以在确定一个对象要被回收之后，再申请内存创建新的对象。
			通过这种方式可以使得程序所消耗的内存维持在一个相对较低的数量。比如下面的代码给出了一个缓冲区的实现示例。
	19、发生了内存泄露或溢出怎么办？
		通过参数 -XX:+HeapDumpOnOutOfMemoryError 让虚拟机在出现OOM异常的时候Dump出内存映像以便于分析。
		一般手段是先通过内存映像分析工具对dump出来的堆转存快照进行分析。
		哪些对象被怀疑为内存泄漏，哪些对象占的空间最大及对象的调用关系，还可以分析线程状态，可以观察到线程被阻塞在哪个对象上，从而判断系统的瓶颈。
		如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。 
		找到引用信息，可以准确的定位出内存泄漏的代码位置。（HashMap中的元素的某些属性改变了，影响了hashcode的值会发生内存泄漏）
		如果不存在内存泄漏，就应当检查虚拟机的参数(-Xmx与-Xms)的设置是否适当，是否可以调大；修改代码逻辑，把某些对象生命周期过长，持有状态时间过长等情况的代码修改。
		内存泄漏的场景：
			（1）使用静态的集合类
			　　静态的集合类的生命周期和应用程序的生命周期一样长，所以在程序结束前容器中的对象不能被释放，会造成内存泄露。
			　　解决办法是最好不使用静态的集合类，如果使用的话，在不需要容器时要将其赋值为null。
			（2）单例模式可能会造成内存泄露（长生命周期的对象持有短生命周期对象的引用）
			　　单例模式只允许应用程序存在一个实例对象，并且这个实例对象的生命周期和应用程序的生命周期一样长，如果单例对象中拥有另一个对象的引用的话，这个被引用的对象就不能被及时回收。
			　　解决办法是单例对象中持有的其他对象使用弱引用，弱引用对象在GC线程工作时，其占用的内存会被回收掉。
			（3）数据库、网络、输入输出流，这些资源没有显示的关闭
			    垃圾回收只负责内存回收，如果对象正在使用资源的话，Java虚拟机不能判断这些对象是不是正在进行操作，比如输入输出，也就不能回收这些对象占用的内存，所以在资源使用完后要调用close()方法关闭。
	20、逃逸分析（escape analysis）技术
		一、VM优化之逃逸分析与分配消除：
			逃逸分析是 JVM 的一项自动分析变量作用域的技术，它可以用来实现某些特殊的优化。
			要了解逃逸分析背后的基本原理，我们先来看下这段有问题的C代码——当然这个是没法用Java来写的：
			int * get_the_int() {
				int i = 42;
				return &amp;i;
			}
			这段C代码在栈上创建了一个int类型的变量，然后把它的指针作为函数的返回值返回了。这样做是有问题的，因为当gettheint()函数返回的时候，int所在的栈帧就已经被销毁了，后面你再去访问这个地址的话，就不知道里面存储的到底是什么了。
			Java平台设计的一个主要目标就是要消除这种类型的bug。从设计上，JVM就不具备这种低级的“根据位置索引来读内存”的能力。这类操作对应的Java字节码是putfield和getfield。
			来看下这段Java代码：
			 public class TestDemo {
			    public static void main(String[] args) throws SQLException {
			        Random random = new Random();
			        int sameArea = 0;
			        for (int i = 0; i < 100000000; i++) {
			            Rect r1 = new Rect(random.nextInt(5), random.nextInt(5));
			            Rect r2 = new Rect(random.nextInt(5), random.nextInt(5));
			            if (r1.sameArea(r2)) {
			                sameArea++;
			            }
			        }
			        System.out.println(sameArea);
			    }
			    static class Rect {
			        private int v;
			        private int h;
			        public Rect(int v, int h) {
			            this.v = v;
			            this.h = h;
			        }
			        public int area() {return v * h;}
			        public boolean sameArea(Rect targer) {return this.area() == targer.area();}
			    }
			}
			main 方法里会创建2亿个 Rect 对象：一亿个r1，一亿个r2，真是这样么？
				不过，如果某个对象只是在方法内部创建并使用的话——也就是说，它不会传递到另一个方法中或者作为返回值返回——那么运行时程序就还能做得更聪明一些。
			你可以说这个对象是没有逃逸出去的，因此运行时（其实就是JIT编译器）做的这个分析又叫做逃逸分析。
				如果一个对象没有逃逸出去，那也就是说JVM可以针对这个对象做一些类似“栈自动分配”的事情。在这个例子当中，这个对象不会从堆上分配空间，因此它也不需要垃圾回收器来回收。
			一旦使用这个“栈分配（stack-allocated）”对象的方法返回了，这个对象所占用的内存也就自动被释放掉了。
				事实上，HotSpot VM的C2编译器做的事情要比栈分配要复杂得多：
				typedef enum {
					// 这个对象可以用标量来代替。这种分配消除技术叫标量替换（scalar replacement）。这意味着这个对象会被拆解成它的构成字段，这就相当于分配对象的操作变成了在方法内部创建多个局部变量。
					// 完成这个之后，另一项HotSpot VM的JIT技术会参与进来，它会将这些字段（事实上已经是局部变量了）存储到CPU的寄存器中（如果有必要就存储在栈上）。
					NoEscape = 1;
					//
					ArgEscape = 2;
					//
					GlobalEscape = 3;
				}
			在上述例子中，如果只看源代码，你会认为r1对象是不会逃逸出main方法外的，但r2会作为参数传给r1的sameArea方法，因此它逃逸出了main方法外。
			根据上面的分类，乍一看的话 r1 应该归类为 NoEscape，而 r2 应该归为 ArgEscape；不过这个结论是错误的，原因有几点：
				Java中的方法调用最终会通过编译器替换为字节码invoke。它会把调用目标（也就是接收对象，注：即要调用的对象）和入参填充到栈中，然后查找到这个方法，再分发给它（也就是执行这个方法）。
			这意味着接收对象也被传入了调用的方法中（它就是调用的方法里的this对象）。因此接收对象也逃逸出了当前域；在这个例子中，这意味着如果逃逸分析分析完这段 Java 代码，r1 和 r2 都会归类为 ArgEscape。
			如果就只是这样的话，那么分配消除的使用场景就很有限了。所幸的是，HotSpot VM能做得更好 sameArea()方法很小（只有17个字节的字节码），在本例中也会被频繁调用，因此它是方法内联（method inlined）的一个理想对象。 
			area()方法的调用的确被内联进了调用方 sameArea()方法里，而 sameArea() 又被内联到了 main()方法的循环体中。
				方法内联是最早的优化，因为它首先把相关联的代码都聚合在了一起，为其它优化打开了大门。现在 sameArea()方法和 area()方法都被内联进来了，方法域的问题不复存在，所有的变量都只在 main 方法的作用域内了。
			也就是说逃逸分析不会再把 r1 和 r2 视作 ArgEscape 类型：方法内联之后，它们现在都被归类为 NoEscape。
				这个结果看起来可能有悖常理，不过你需要记住的是JIT编译器并不是通过原始代码来进行优化的。
			前面的例子中，这些对象的分配都不会在堆上进行了，会把它们的字段拆解成独立的值。寄存器分配器通常会把拆解出来的字段直接放到寄存器中，不过如果没有足够可用的寄存器，那剩下的字段会被存储到栈上。
			这种情况被称为栈溢出（stack spill，注：和stack overflow不同）。
				现代JVM中逃逸分析是默认开启的，如果针对上述代码进行GC 日志分析，可以看到根本没有发生GC事件，只是在进程退出时往日志里记录了下堆的摘要信息。通过JVM参数-XX:-DoEscapeAnalysis来关掉它后发现，由于Eden区空间满了，
			导致了内存分配失败、需要进行垃圾回收，因此触发了GC事件。
		========================================================================================================================================================================================================
		二、JVM优化之逃逸分析及锁消除：
			如果能确认某个加锁的对象不会逃逸出局部作用域，就可以进行锁删除。这意味着这个对象同时只可能被一个线程访问，因此也就没有必要防止其它线程对它进行访问了。这样的话这个锁就是可以删除的。这个便叫做锁消除。

			StringBuffer是一个使用同步方法的线程安全的类，它可以用来很好地诠释锁消除。StringBuffer是Java1.0的时候开始引入的，可以用来高效地拼接不可变的字符串对象。它对所有append方法都进行了同步操作，
			以确保当多个线程同时写入同一个StringBuffer对象的时候也能够保证构造中的字符串可以安全地创建出来：
				@Override
			    public synchronized StringBuffer append(String str) {
			        toStringCache = null;
			        super.append(str);
			        return this;
			    }
			StringBuilder：
				@Override
			    public StringBuilder append(String str) {
			        super.append(str);
			        return this;
			    }
			调用 StringBuffer 的 append 方法的线程，必须得获取到这个对象的内部锁（也叫监视器锁）才能进入到方法内部，在退出方法前也必须要释放掉这个锁。
			不过在 HotSpot 虚拟机引入了逃逸分析之后，在调用像 StringBuffer 这样的对象的同步方法时，就能够自动地把锁消除掉了。这只会出现在方法域内部所创建的对象上，只有这样才能保证不会发生逃逸。
			在 Java 8 中它是默认开启的，不过你也可以通过-XX:-DoEscapeAnalysis 这个 VM参数来关掉它，这样可以看下优化的效果。

			锁粗化：
				当连续获取同一个对象的锁时，HotSpot 虚拟机会去检查多个锁区域是否能合并成一个更大的锁区域。这种聚合被称作锁粗化，它能够减少加锁和解锁的消耗。
				当 HotSpot JVM发现需要加锁时，它会尝试往前查找同一个对象的解锁操作。如果能匹配上，它会考虑是否要将两个锁区域作合并，并删除一组 解锁/加锁 操作。
				锁粗化是默认开启的，不过也可以通过启动参数 -XX:-EliminateLocks 来关掉它。
			嵌套锁：
				同步块可能会一个嵌套一个，进而两个块使用同一个对象的监视器锁来进行同步也是很有可能的。这种情况我们称之为嵌套锁，HotSpot虚拟机是可以识别出来并删除掉内部块中的锁的。
				Java 8 中的嵌套锁删除只有在锁被声明为 static final 或者锁的是 this 对象时才可能发生。
				嵌套锁优化是默认开启的，不过也可以通过启动参数-XX:-EliminateNestedLocks来关掉它。
			数组及逃逸分析：
					非堆上分配的空间要么存储在栈上，要么就在CPU寄存器中，这些都是相对稀缺的资源，因此逃逸分析和其它优化一样，（在实现上）肯定会面临妥协。HotSpot JVM 上的一个默认限制是大于 64 个元素的数组不会进行逃逸分析优化。
				这个大小可以通过启动参数 -XX:EliminateAllocationArraySizeLimit=n 来进行控制，n 是数组的大小。
					假设有段热点代码，它会去分配一个临时数组用于从缓存中读取数据。如果逃逸分析发现这个数组的作用域没有逃逸出方法体外，便不会在堆上分配内存。不过如果数组大小超过64的话（哪怕并不是全都用到）便仍会存储到堆里。
				这样数组的逃逸分析优化便不会起作用，也仍会从堆内分配内存。

	21、是不是所有的对象和数组都会在堆内存分配空间？
		有一种特殊情况，那就是如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。

Sentinel 原理剖析
=============================================================================================================================================================
=============================================================================================================================================================
JUC/并发相关
	1、简述 AQS 的实现原理、concurrent 包中使用过哪些类？分别说说使用在什么场景？为什么要使用？Condition 接口及其实现原理
		JUC 下的支持并发类：
			AQS：AbstractQueuedSynchronizer（其中的部分核心方法可结合下边的 CountDownLatch 进行分析）
					AQS 是一个 FIFO 的双向队列，其内部通过节点 head 和 tail 记录队首和队尾元素，队列元素的类型为 Node。其中 Node 中的 thread 变量用来存放进入 AQS
				队列里面的线程： Node 节点内部的 SHARED 用来标记该线程是获取共享资源时被阻塞挂起后放入 AQS 队列的， EXCLUSIVE 用来标记线程是获取独占资源时被挂起后放入
				AQS 队列的 ； waitStatus 记录当前线程等待状态，可以为 CANCELLED （线程被取消了）、SIGNAL（ 线程需要被唤醒）、 CONDITION（线程在条件队列里面等待〉、 PROPAGATE（释
				放共享资源时需要通知其他节点〕； prev 记录当前节点的前驱节点， next 记录当前节点的后继节点。
					AQS 有个内部类 ConditionObject，用来结合锁实现线程同步。ConditionObject 可以直接访问 AQS 对象内部的变量，比如 state 状态值和 AQS 队列。 ConditionObject 是条件
				变量，每个条件变量对应一个条件队列（单向链表队列），其用来存放调用条件变量的 await 方法后被阻塞的线程，这个条件队列的头、尾元素分别为为 firstWaiter 和 lastWaiter。
					对于 AQS 来说，线程同步的关键是对状态值 state 进行操作 。 根据 state 是否属于一个线程，操作 state 的方式分为独占方式和共享方式。 
					在独占方式下获取和释放资源的方法为：void acquire(int arg);         void acquirelnterruptibly(int arg);         boolean release(int arg)。
					在共享方式下获取和释放资源的方法为：void acquireShared(int arg);   void acquireSharedinterruptibly(int arg);   boolean reaseShared(int arg)。
					tryAcquire 等以try开头的方法，会直接返回不会阻塞。
					不带 Intenuptibly 关键字的方法的意思是不对中断进行响应，也就是线程在调用不带 Interruptibly 关键字的方法获取资源时或者获取资源失败被挂起时，其他线程中断了
				该线程，那么该线程不会因为被中断而抛出异常，它还是继续获取资源或者被挂起，也就是说不对中断进行响应，忽略中断 。
					AQS 提供的队列，主要看入队操作： 当一个线程获取锁失败后该线程会被转换为 Node 节点，然后就会使用 enq(final Node node）方法将该节点插入到 AQS 的阻塞队列：第一次循环 head 与 tail 指向一个哨兵节点。第二次循环将当前节点插入队尾。
					notify 和 wait，是配合 synchronized 内置锁实现线程间同步的基础设施一样，条件变量的 signal 和 await 方法也是用来配合锁（使用 AQS 实现的锁〉实现线程间同步的基础设施。AQS 的一个锁可以对应多个条件变量。

					ReentrantLock lock = new ReentrantLock(); // (l)
			        Condition condition = lock.newCondition(); // (2)
			        lock.lock(); // (3) 阻塞，当多个线程同时调用 lock.lock（）方法获取锁时，只有一个线程获取到了锁，其他线程会被转换为 Node 节点插入到 lock 锁对应的 AQS 阻塞队列里面，并做自旋 CAS 尝试获取锁
			        try {
			            System.out.println("begin wait");
			            condition.await(); // (4) 放入条件队列末尾，并阻塞在这里。这时候因为调用 lock.lock（）方法被阻塞到 AQS 队列里面的一个线程会获取到被释放的锁
			            System.out.println("end wait");
			        } catch (Exception e) {
			            e.printStackTrace();
			        } finally {
			            lock.unlock(); // (5)
			        }
			        lock.lock(); // (6)
			        try {
			            System.out.println("begin signal");
			            condition.signal(); // (7) 当另外一个线程调用条件变量的 signal或 signalAll 方法时（必须先调用锁的 lock()方法获取锁），在内部会把条件队列里面队头的一个或全部线程节点从条件队列里面移除并放入 AQS 的阻塞队列里面，然后激活这个线程
			            System.out.println("ed signal");
			        } catch (Exception e) {
			            e.printStackTrace();
			        } finally {
			            lock.unlock();  // (8)
			        }
			LockSupport 工具：
				主要作用是挂起和唤醒线程，该工具类是创建锁和其他同步类的基础。
				LockSupport 是使用 Unsafe 类实现的，下面介绍 LockSupport 中的几个主要函数：
					一、void park() 方法
						如果调用 park 方法的线程已经拿到了与 LockSupport 关联的许可证，则调用 Locksupport.park（）时会马上返回，否则调用线程会被禁止参与线程的调度，也就是会被阻塞挂起。
						public static void main(String[] args) throws InterruptedException {
					        System.out.println("child begin park");
					        LockSupport.park(); // 会永远阻塞在这里
					        System.out.println("child  end  park");
					    }
					    在其他线程调用 unpark(Thread thread）方法并且将当前线程作为参数时，调用 park 方法而被阻塞的线程会返回。另外，如果其他线程调用了阻塞线程的 interrupt()方法，设置
						了中断标志或者线程被虚假唤醒，则阻塞线程也会返回。所以在调用 park 方法时最好也使用循环条件判断方式。需要注意的是，因调用 park() 方法而被阻塞的线程被其他线程中断而返回时并不会抛出 InterruptedException 异常。
					二、void unpark(Thread thread）方法
						当一个线程调用 unpark 时，如果参数 thread 线程没有持有 thread 与 LockSupport 类关联的许可证，则让 thread 线程持有。 如果 thread 之前因调用 park（）而被挂起，则调用unpark 后，该线程会被唤醒。 
						如果 thread 之前没有调用 park，则调用 unpark 方法后，再调用 park 方法，其会立刻返回。
						public static void main(String[] args) throws InterruptedException {
					        System.out.println("child begin park");
					        LockSupport.unpark(Thread.currentThread());
					        LockSupport.park(); // 该处会直接返回
					        System.out.println("child  end  park");
					    }
						首先看个例子：
							Thread thread = new Thread(() -> {
					            System.out.println("child begin park");
					            LockSupport.park();
					            System.out.println("child  end  park");
					        });
					        thread.start();
					        Thread.sleep(5000);
					        System.out.println("main begin unPark");
					        LockSupport.unpark(thread);
				        这个例子看起来没什么问题，“但是”来了，park 方法返回时不会告诉你因何种原因返回，所以调用者需要根据之前调用 park 方法的原因，再次检查条件是否满足，如果不满足则还需要再次调用 park 方法。
				        接着看下例：
					        Thread thread = new Thread(() -> {
					            System.out.println("child begin park");
					            while (!Thread.currentThread().isInterrupted()) {// 根据调用前后中断状态的对比就可以判断是不是因为被中断才返回的
					                LockSupport.park();
					            }
					            System.out.println("child  end  park");
					        });
					        thread.start();
					        Thread.sleep(5000);
					        System.out.println("main begin unPark");
					        LockSupport.unpark(thread); // 只有中断子线程，子线程才会运行结束，如果子线程不被中断，即使调用 unpark(thread）方法子线程也不会结束
					        System.out.println("child unPark preparing...");
					        Thread.sleep(5000);
					        System.out.println("child unPark begin");
					        thread.interrupt(); // 其他线程调用了阻塞线程的 interrupt()方法，设置了中断标志或者线程被虚假唤醒，则阻塞线程也会返回。
					三、void parkNanos(long nanos）方法
						如果没有拿到许可证，则调用线程会被挂起 nanos 时间后修改为自动返回。
					四、void park(Object blocker）方法
						public static void park(Object blocker) {
					        Thread t = Thread.currentThread();
					        setBlocker(t, blocker);
					        UNSAFE.park(false, 0L);
					        setBlocker(t, null);
					    }
					    private static void setBlocker(Thread t, Object arg) {
					        UNSAFE.putObject(t, parkBlockerOffset, arg);
					    }
						当线程在没有持有许可证的情况下调用 park 方法而被阻塞挂起时，这个 blocker 对象会被记录到该线程内部。
						使用诊断工具可以观察线程被阻塞 的原因，诊断工具是通过调用 getBlocker(Thread thread)方法来获取 blocker 对象的，所以 JDK 推荐我们使用带有 blocker 参数的 park 方法，并且blocker 被设置为 this，
						这样当在打印线程堆横排查问题时就能知道是哪个类被阻塞了。使用带 blocker 参数的 park 方法，线程堆枝可以提供更多有关阻塞对象的信息。
						Thread 类里面有个变量 volatile Object parkBlocker，用来存放 park 方法传递的 blocker 对象，也就是把 blocker 变量存放到了调用 park 方法的线程的成员变量里面。
			1）、ThreadLocalRandom
					每个 Random 实例里面都有一个原子性的种子变量用来记录当前的种子值，当要生成新的随机数时需要根据当前种子计算新的种子并更新回原子变量。在多线程下使用单个 Random 实例生成随机数时，
				当多个线程同时计算随机数来计算新的种子时，多个线程会竞争同一个原子变量的更新操作，由于原子变量的更新是 CAS 操作，同时只有一个线程会成功，所以会造成大量线程进行自旋重试，这会降低并发性能，
				所以 ThreadLocalRandom 应运而生。
					ThreadLocalRandom 类继承了 Random 类并重写了 nextlnt 方法，在 ThreadLocalRandom 类中并没有使用继承自 Random 类的原子性种子变量。在 ThreadLocalRandom 中并没有存放具体的种子，
				具体的种子存放在具体的调用线程的 threadLocalRandomSeed 变量里面。 ThreadLocalRandom 类似于 ThreadLocal 类 ，就是个工具类。 当线程调用 ThreadLocalRandom 的 current 方法时， 
				ThreadLocalRandom 负责初始化调用线程的 threadLocalRandomSeed 变量，也就是初始化种子。当调用 ThreadLocalRandom 的 nextInt 方法时，实际上是获取当前线程的 threadLocalRandomSeed 
				变量作为当前种子来计算新的种子，然后更新新的种子到当前线程的 threadLocalRandomSeed 变量，而后再根据新种子并使用具体算法计算随机数。这里需要注意的是，threadLocalRandomSeed 变量就是 
				Thread 类里面的一个普通 long 变量，它并不是原子性变量。 其实道理很简单，因为这个变量是线程级别的，所以根本不需要使用原子性变量。
			2）、LongAdder
				使用 AtomicLong 时，在高并发下大量线程会同时去竞争更新同一个原子变量，但是由于同时只有一个线程的 CAS 操作会成功，这就造成了大量线程竞争失败后，会通过无限循环不断进行自旋尝试 CAS 的操作，而这会白白浪费 CPU 资源。
				因此 JDK 8 新增了一个原子性递增或者递减类 LongAdder 用来克服在高并发下使用 AtomicLong 的缺点。 AtomicLong 的性能瓶颈是由于过多线程同时去竞争一个变量的更新而产生的，那么如果把一个变量分解为多个变量，
				让同样多的线程去竞争多个资源，就是 LongAddr 的解决思路。
			3）、CopyOnWriteArrayList（无界）
					CopyOnWrite 容器即写时复制的容器。
					通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行 Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，
				再将原容器的引用指向新的容器。这样做的好处是我们可以对 CopyOnWrite 容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以 CopyOnWrite 容器也是一种读写分离的思想，读和写不同的容器。
					public boolean add(E e) {...} 由于加了锁（RetreenLock 独占锁），所以整个 add 过程是个原子性操作。需要注意的是，在添加元素时，首先复制了一个快照，然后在快照上进行添加，而不是直接在原来数组上进行。
					写时复制策略会产生的弱一致性问题 ：在通过 get(int index) 获取指定下标下的元素时，该方法并没有加锁，也就是获取队列数组内存指向空间和从队列指定下标处取出指定元素两个步骤之间并不是原子性操作。
				如果这两个步骤之间别的线程通过 remove(先获取独占锁再拷贝一份原有数据，并在拷贝的数据的内存地址上进行删除操作)进行删除当前线程要获取的数据，并将队列元素指向地址重新指向了这儿新的内存地址。但是当前
				线程访问的还是旧的内存指向空间，还是能继续根据数组下标访问到要访问的元素。
					遍历列表元素可以使用法代器，也存在上述的弱一致性问题。
					CopyOnWriteArrayList 使用写时复制的策略来保证 list 的一致性，而获取一修改一写入三步操作并不是原子性的，所以在增删改的过程中都使用了独占锁，来保证在某个时间只有一个线程能对 list 数组进行修改。 
				另外 CopyOnWriteArrayList 提供了弱一致性的法代器，从而保证在获取迭代器后，其他线程对 list 的修改是不可见的，迭代器遍历的数组是一个快照。 另外，CopyOnWriteArraySet 的底层就是使用它实现的。
					另外一个问题就是内存占用问题。
			4）、ReentrantLock
					ReentrantLock 的底层是使用 AQS 实现的可重入独占锁。 在这里 AQS 状态值为 0 表示当前锁空闲，为大于等于 l 的值则说明该锁己经被占用。 该锁内部有公平与非公平实现，默认情况下是非公平的实现。 
				另外，由于该锁是独占锁，所以某时只有一个线程可以获取该锁。
					所谓的公平与非公平是指：
							首先非公平是说先尝试获取锁的线程并不一定比后尝试获取锁的线程优先获取锁。这里假设线程 A 调用 lock()方法时执行到 nonfairTryAcquire 发现当前
						状态值不为 0，然后发现当前线程不是线程持有者，则返回 false，然后当前线程被放入 AQS 阻塞队列。这时候线程 B 也调用了 lock（） 方法执行到 nonfairTryAcquire，
						发现当前状态值为 0 了 （ 假设占有该锁的其他线程释放了该锁），所以通过 CAS 设置获取到了 该锁。明明是线程 A 先请求获取该锁呀，这就是非公平的体现。这里线程 B 
						在获取锁前并没有查看当前 AQS 队列里面是否有比自己更早请求该锁的线程 ， 而是使用了抢夺策略。
							公平的实现是核心代码是 hasQueuedPredecessors 方法，也就是设置队列的状态 state 值时，会先调用这个方法，即先判断当前节点是否有前驱节点。	注意这里有
			5）、ReentrantReadWritelock
					采用读写分离的策略，允许多个线程可以同时获取读锁。
					读写锁的内部维护了一个 ReadLock 和一个 WriteLock，它们依赖 Sync 实现具体功能。而 Sync 继承自 AQS，并且也提供了公平和非公平的实现。
					ReentrantReadWriteLock 巧妙地使用 state 的高 16 位表示读状态，也就是获取到读锁的次数；使用低 16 位表示获取到写锁的线程的可重入次数。
		线程：
			1）、三种线程创建方式，分别为实现 Runnable 接口的 run 方法，继承 Thread 类并重写 run 的方法，使用 FutureTask 方式 。
				一、继承 Thread 类并重写 run 的方法
					调用了 start 方法后才真正启动了线程。其实调用 start 方法后线程并没有马上执行而是处于就绪状态，这个就绪状态是指该线程已经获取了除 CPU 资源外的其他资源，等待获取 CPU 资源后才会真正处于运行状态。
					一旦 run 方法执行完毕，该线程就处于终止状态。不好的地方是 Java 不支持多继承，如果继承了 Thread 类，那么就不能再继承其他类。另外任务与代码没有分离，当多个线程执行一样的任务时需要多份任务代码。
				二、实现 Runnable 接口：
					两个线程共用一个 task 代码逻辑，如果需要，可以给 RunableTask 添加参数进行任务区分。另外，RunableTask 可以继承其他类。但是上面介绍的两种方式都有一个缺点，就是任务没有返回值。
				三、使用 FutureTask 的方式：
					实现 Callable 接口的 call（）方法。在 main 函数内首先创建一个 FutrueTask 对象（构造函数为 CallerTask 的实例），然后使用创建的 FutrueTask 对象作为任务创建了一个线程并且启动它，
					最后通过 futureTask.get(）等待任务执行完毕并返回结果。
			2）、线程中断：
				线程中断是一种线程间的协作模式，通过设置线程的中断标志并不能直接终止该线程的执行，而是被中断的线程根据中断状态自行处理。
				void interrupt() 方法： 中断线程。 例如，当线程 A 运行时，线程 B 可以调用钱程 A 的 interrupt() 方法来设置线程 A 的中断标志为 true 并立即返回。设置标志仅仅是设置标志，线程 A 实际并没有被中断，
					它会继续往下执行。如果线程 A 因为调用了 wait 系列函数、 join 方法或者 sleep 方法而被阻塞挂起，这时候若线程 B 调用线程A 的 interrupt（） 方法，线程 A 会在调用这些方法的地方抛出 InterruptedException 
					异常而返回。
				boolean isInterrupte() 方法： 检测当前线程是否被中断。如果是返回 true，否则返回 false。
					public boolean isInterrupted(){
						//传递 false ，说明不清除中断标志
						return isInterrupted(false) ;
					}
				boolean interrupted() 方法： 检测当前线程是否被中断，如果是返回 true，否则返回 false。与 isInterrupted 不同的是，该方法如果发现当前线程被中断，则会清除中断标志，并且该方法是 static 方法 ，
					可以通过 Thread 类直接调用。另外从下面的代码可以知道，在 interrupted() 内部是获取当前调用线程的中断标志而不是调用 interrupted() 方法的实例对象的中断标志。
					public static boolean interrupted() {
						// 清除 中断标志
						return currentThread().isinterrupted(true);
					}
				// 线程退出条件
				while (!Thread.currentThread().isInterrupted() && more work to do) {
					// do more work;	
				}
			3）、如何避免线程死锁
				要想避免死锁，只需要破坏掉至少一个构造死锁的必要条件即可，只有请求并持有和环路等待条件是可以被破坏的。造成死锁的原因其实和申请资源的顺序有很大关系，使用资源申请的有序性原则就可以避免死锁。
			4）、守护线程与用户线程
				区别之一是当最后一个非守护线程结束时，JVM 会正常退出，而不管当前是否有守护线程，也就是说守护线程是否结束并不影响 JVM 的退出。言外之意，只要有一个用户线程还没结束，正常情况下 JVM 就不会退出。
				父线程结束后，子线程还是可以继续存在的，也就是子线程的生命周期并不受父线程的影响。
			5）、ThreadLocal、ThreadLocalMap、Thread、InheritableThreadLocal
					Thread 类中有一个 threadLocals 和一个 inheritableThreadLocals，它们都是 ThreadLocalMap 类型的变量，而 ThreadLocalMap 是一个定制化的 Hashmap。 在默认情况下，每个线程中的这两个变量都为 null，
				只有当前线程第一次调用 ThreadLocal 的 set 或者 get 方法时才会创建它们。 其实每个线程的本地变量不是存放在 ThreadLocal 实例里面，而是存放在调用线程的 threadLocals 变量里面。 也就是说，ThreadLocal 类型
				的本地变量存放在具体的线程内存空间中。 ThreadLocal 就是一个工具壳，它通过 set 方法把 value 值放入调用线程的 threadLocals 里面并存放起来， 当调用线程调用它的 get 方法时，再从当前线程的 threadLocals 
				变量里面将其拿出来使用。 如果调用线程一直不终止，那么这个本地变量会一直存放在调用线程的 threadLocals 变量里面，所以当不需要使用本地变量时可以通过调用 ThreadLocal 变量的 remove 方法，从当前线程的 
				threadLocals 里面删除该本地变量。另外，Thread 里面的 threadLocals 为何被设计为 map 结构？很明显是因为每个线程可以关联多个 ThreadLocal 变量。
				但是来了：
					但是一、造成内存溢出
						每个线程的本地变量存放在线程自己的内存变量 threadLocals 中，如果当前线程一直不消亡，那么这些本地变量会一直存在，所以可能会造成内存溢出，因此使用完毕后要记得调用 ThreadLocal 的 remove 方法删除
						对应线程的 threadLocals 中的本地变量。在高级篇要讲解的只 JUC 包里面的 ThreadLocalRandom，就是借鉴 ThreadLocal 的思想实现的。
					但是二、Threadlocal 不支持继承性
						同一个 ThreadLocal 变量在父线程中被设置值后，在子线程中是获取不到的。因为在子线程 thread 里面调用 get 方法时当前线程为 thread 线程，而调用 set 方法设置线程变量的是父线程，两者是不同的
						线程，自然子线程访问时返回 null。那么有没有办法让子线程能访问到父线程中的值？ 答案是有，那就是 InheritableThreadLocal。
				InheritableThreadLocal 实现原理大致如下：
					在创建子线程的时候，会把父线程的 inheritableThreadLocals 变量中的值拷贝一份到子线程的 inheritableThreadLocals 变量，也就是说当父线程创建子线程时，构造函数会把父线程中 inheritableThreadLocals 
					变量里面的本地变量复制一份保存到子线程的 inheritableThreadLocals 变量里面。
			
			7）、AtomicStampedReference 可以解决 CAS 的 ABA 问题。

			8）、Thread start() run() 方法的区别：
					1.When a program calls the start() method, a new thread is created and then the run() method is executed. But if we directly call the run() method then no new thread will be 
				created and run() method will be executed as a normal method call on the current calling thread itself and no multi-threading will take place.
					2.another most important difference between start() and run() method is that we can’t call the start() method twice otherwise it will throw an IllegalStateException whereas 
				run() method can be called multiple times as it is just a normal method calling.
	2、简述 ConcurrentLinkedQueue 和 LinkedBlockingQueue 的用处和不同之处
		a）、ConcurrentLinkedQueue：（多线程同时操作一个 collection 时使用）
			CAS 算法实现的线程安全的无界非阻塞队列，其底层数据结构使用单向链表实现，对于入队和出队操作使用 CAS 来实现线程安全。按FIFO原则进行排序。
			入队、出队都是操作使用 volatile 修饰的 tail、 head 节点，要保证在多线程下出入队线程安全，只需要保证这两个 Node 操作的可见性和原子性即可。
			由于 volatile 本身可以保证可见性，所以只需要保证对两个变量操作的原子性即可。
		b）、LinkedBlockingQueue：（一般用于生产者消费者场景）
				独占锁实现的单向链表(head为哨兵节点)阻塞队列，AutomicInteger 原子变量记录队列元素个数，两个 ReentrantLock 的实例，分别用来控制元素入队和出队的原子性，
			notEmpty 和 notFull 是条件变量 ，它们内部都有一个条件队列用来存放进队和出队时被阻塞的线程，其实这是生产者一消费者模型。默认队列容量为 Ox7fffffff，用户也可以自己指定容量，
			所以从一定程度上可以说 LinkedBlockingQueue 是有界阻塞队列。
		c）、ArrayBlockingQueue：
				有界数组方式实现的阻塞队列，putIndex 变量表示入队元素下标，takeIndex 是出队下标，count
			统计队列元素个数。 从定义可知，这些变量并没有使用 volatile 修饰，这是因为访问这些变量都是在锁块内，而加锁己经保证了锁块内变量的内存可见性了。 
			另外有个独占锁 lock 用来保证出、入队操作的原子性，这保证了同时只有一个线程可以进行入队、出队操作。 另外，notEmpty、 notFull 条件变量用来进行出、入队的同步。
		d）、PriorityBlockingQueue：
				带优先级的无界阻塞队列，每次出队都返回优先级最高或者最低的元素。其内部是使用平衡二叉树堆实现的，所以直接遍历队列元素不保证有序。默认使用对象的 compareTo 方法提供比较规则，
			如果你需要自定义比较规则则可以自定义 comparators。
				PriorityBlockingQueue 类似于 ArrayBlockingQueue，在内部使用一个独占锁来控制同时只有一个线程可以进行入队和出队操作。另外，前者只使用了一个 notEmpty 条件变量而没有使用 notFull，
			这是因为前者是无界队列，执行 put 操作时永远不会处于 await 状态，所以也不需要被唤醒。而 take 方法是阻塞方法，并且是可被中断的。当需要存放有优先级的元素时该队列比较有用。
		e）、DelayQueue：
				DelayQueue 并发队列是一个无界阻塞延迟队列，队列中的每个元素都有个过期时间，当从队列获取元素时，只有过期元素才会出队列。队列头元素是最快要过期的元素。
			其内部使用 PriorityQueue 存放数据，使用 ReentrantLock 实现线程同步。另外队列里面的元素要实现 Delayed 接口，其中一个是获取当前元素到过期时间剩余时间的接口，在出队时判断元素是否过期了，
			一个是元素之间比较的接口，因为这是一个有优先级的队列。
	3、Synchronized 和 Lock 的区别
		a.Lock 是一个接口，而 synchronized 是 Java 中的关键字，synchronized 是内置的语言实现；
		b.synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而 Lock 在发生异常时，如果没有主动通过 unLock() 去释放锁，则很可能造成死锁现象，因此使用 Lock 时需要在 finally 块中释放锁；
		    这是因为 synchronized 编译成字节码指令后，会对应一个 monitorenter 和两个 monitorexit 一个在流程正常结束时调用，一个在异常发生时调用。
		c.Lock 可以让等待锁的线程响应中断，而 synchronized 却不行，使用 synchronized 时，等待的线程会一直等待下去，不能够响应中断；
		d.通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。
		e.性能上来说，在资源竞争不激烈的情形下，Lock 性能稍微比 synchronized 差点（编译程序通常会尽可能的进行优化 synchronized ）。但是当同步非常激烈的时候，synchronized 的性能一下子能下降好几十倍。而 ReentrantLock 还能维持常态。
	4、synchronized 的原理
		a.synchronized 的内存语义
				这个内存语义就可以解决共享变量内存可见性问题。进入 synchronized 块的内存语义是把在 synchronized 块内使用到的变量从线程的工作内存中清除，这样在 synchronized 块内使用到该变量时就不会从线程的工作内存中获取，
			而是直接从主内存中获取。 退出 synchronized 块的内存语义是把在 synchronized 块内对共享变量的修改刷新到主内存。其实这也是加锁和释放锁的语义，当获取锁后会清空锁块内本地内存中将会被用到的共享变量，在使用这些
			共享变量时从主内存进行加载，在释放锁时将本地内存中修改的共享变量刷新到主内存。除可以解决共享变量内存可见性问题外，synchronized 经常被用来实现原子性操作。
				另外请注意，synchronized 关键字会引起线程上下文切换并带来线程调度开销。
		b.volatile 关键字
				当一个变量被声明为 volatile 时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是会把值刷新回主内存。 当其他线程读取该共享变量时，会从主内存重新获取最新值，而不是使用当前线程的工作 内存中的值。 
			volatile 的内存语义和 synchronized 有相似之处，具体来说就是，当线程写入了 volatile 变量值时就等价于线程退出 synchronized 同步块（把写入工作内存的变量值同步到主内存），读取 volatile 变量值时就相当于
			进入同步块（先清空本地内存变量值，再从主内存获取最新值）。
				另外，通过把变量声明为 volatile 可以避免指令重排序问题。写 volatile 变量时，可以确保 volatile 写之前的操作不会被编译器重排序到 volatile 写之后。 读 volatile 变量时，可以确保 volatile 读之后的操作
			不会被编译器重排序到 volatile 读之前。
				但是又开始了，volatile 虽然提供了可见性保证，但并不保证操作的原子性。
				写入变量值不依赖、变量的当前值时、读写变量值时没有加锁时候可以使用 volatile 对变量就行修饰。
		Java 中提供了两种实现同步的基础语义：synchronized 方法和 synchronized 块：
			public class SyncTest {
			    public void syncBlock() {
			        synchronized (this) {
			            System.out.println("hello block");
			        }
			    }
			    public synchronized void syncMethod() {
			        System.out.println("hello method");
			    }
			}
		https://github.com/farmerjohngit/myblog/issues/12
		当 SyncTest.java 被编译成 class 文件的时候，synchronized 关键字和 synchronized 方法的字节码略有不同，我们可以用 javap -v 命令查看 class 文件对应的JVM字节码信息，部分信息如下：
		在JVM底层，对于这两种 synchronized 语义的实现大致相同
			{
			  public void syncBlock();
			    descriptor: ()V
			    flags: ACC_PUBLIC
			    Code:
			      stack=2, locals=3, args_size=1
			         0: aload_0
			         1: dup
			         2: astore_1
			         3: monitorenter				 	  // monitorenter指令进入同步块
			         4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
			         7: ldc           #3                  // String hello block
			         9: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
			        12: aload_1
			        13: monitorexit						  // monitorexit指令退出同步块
			        14: goto          22
			        17: astore_2
			        18: aload_1
			        19: monitorexit						  // monitorexit指令退出同步块 两个monitorexit指令的原因是：为了保证抛异常的情况下也能释放锁，所以javac为同步代码块添加了一个隐式的try-finally，在finally中会调用monitorexit命令释放锁
			        20: aload_2
			        21: athrow
			        22: return
			      Exception table:
			         from    to  target type
			             4    14    17   any
			            17    20    17   any
			 
			  public synchronized void syncMethod();
			    descriptor: ()V
			    flags: ACC_PUBLIC, ACC_SYNCHRONIZED      //添加了ACC_SYNCHRONIZED标记 在JVM进行方法调用时，发现调用的方法被 ACC_SYNCHRONIZED 修饰，则会先尝试获得锁
			    Code:
			      stack=2, locals=1, args_size=1
			         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
			         3: ldc           #5                  // String hello method
			         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
			         8: return
			}
		JDK 1.6引入了两种新型锁机制：偏向锁和轻量级锁，它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。
		对象头，它是实现多种锁机制的基础，因为在 Java 中任意对象都可以用作锁，因此必定要有一个映射关系，存储该对象以及其对应的锁信息（比如当前哪个线程持有锁，哪些线程在等待）。
		在JVM中，对象在内存中除了本身的数据外还会有个对象头，对于普通对象而言，其对象头中有两类信息：mark word 和类型指针。另外对于数组而言还会有一份记录数组长度的数据。
		类型指针是指向该对象所属类对象的指针，mark word 用于存储对象的 HashCode、GC分代年龄、锁状态等信息。在 32 位系统上 mark word 长度为 32 bit，64 位系统上长度为 64 bit。
		图片见：https://camo.githubusercontent.com/ba0c739510c9092e06a37903670441072239d7c7/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31312f32382f313637353964643162306239363236383f773d37323026683d32353026663d6a70656726733d3337323831
		当对象状态为偏向锁（biasable）时，mark word 存储的是偏向的线程ID；当状态为轻量级锁（lightweight locked）时，mark word 存储的是指向线程栈中 Lock Record 的指针；当状态为重量级锁（inflated）时，为指向堆中的 monitor 对象的指针。

		synchronize 性能优化：
			JDK 1.6中对 synchronize 的实现进行了各种优化，使得它显得不是那么重了，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
			锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
			优化技术：
				a.自旋锁：
					线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对 CPU 来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时我们发现在许多应用上面，
					对象锁的锁状态只会持续很短一段时间，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。
					所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。
				b.适应自旋锁：
					所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
					线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。
					反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。有了自适应自旋锁，
					随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。
				c.锁消除：
					JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。
					如 StringBuffer、Vector、HashTable 等，这个时候会存在隐形的加锁操作。
					public void vectorTest() {
					    Vector<String> vector = new Vector<String>();
					    for(int i = 0 ; i < 10 ; i++) {
					        vector.add(i + "");
					    }
					    System.out.println(vector);
					}
					在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。
				d.锁粗化：
					如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗化的概念。
					将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。
					如上面实例：vector 每次 add 的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到 for 循环之外。
			锁状态（无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态 4 种）：
				偏向锁：
					通俗的讲，偏向锁就是在运行过程中，对象的锁偏向某个线程。即在开启偏向锁机制的情况下，某个线程获得锁，当该线程下次再想要获得锁时，不需要再获得锁（即忽略 synchronized 关键词），直接就可以执行同步代码，比较适合竞争较少的情况。
					偏向锁的获取流程：
						（1）查看 Mark Word 中偏向锁的标识以及锁标志位，若偏向锁标识为1且锁标志位为01，则该锁为可偏向状态。
						（2）若为可偏向状态，则测试 Mark Word 中的线程ID是否与当前线程相同，若相同，则直接执行同步代码，否则进入下一步。
						（3）当前线程通过CAS操作竞争锁，若竞争成功，则将 Mark Word 中线程 ID 设置为当前线程ID，然后执行同步代码，若竞争失败，进入下一步。
						（4）当前线程通过CAS竞争锁失败的情况下，说明有竞争。当到达全局安全点时之前获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。
					偏向锁的释放流程：
						偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁状态的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的撤销需要等待全局安全点（即没有字节码正在执行），它会暂停拥有偏向锁的线程，
						撤销后偏向锁恢复到未锁定状态或轻量级锁状态。
					偏向锁对 synchronized 关键词的优化在单个线程中或竞争较少的线程中是很成功的。但是在多线程竞争十分频繁的情况下，偏向锁不仅不能提高效率，反而会因为不断地重新设置偏向线程ID等其他消耗而降低效率。
					例子：
						/**
					     * 开启偏向锁参数：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0  耗时2400ms左右
					     * 禁用偏向锁参数：-XX:-UseBiasedLocking  耗时800ms左右
					     */
					    public static void main(String[] args) throws InterruptedException {
					        long time1 = System.currentTimeMillis();
					        Vector<Integer> vector = new Vector<Integer>();
					        for (int i = 0; i < 100000000; i++) {
					            vector.add(100);//add是synchronized操作
					        }
					        System.out.println(System.currentTimeMillis() - time1);
					    }
				轻量级锁：
					很多情况下，在 Java 程序运行时，同步块中的代码都是不存在竞争的，不同的线程交替的执行同步块中的代码。这种情况下，用重量级锁是没必要的。因此JVM引入了轻量级锁的概念。
					轻量级锁不是用来替代传统的重量级锁的，而是在没有多线程竞争的情况下，使用轻量级锁能够减少性能消耗，但是当多个线程同时竞争锁时，轻量级锁会膨胀为重量级锁。
					线程在执行同步块之前，JVM  会先在当前的线程的栈帧中创建一个 Lock Record，其包括一个用于存储对象头中的 mark word（官方称之为 Displaced Mark Word ）以及一个指向对象的指针。
					参考图片：https://camo.githubusercontent.com/3579362e569b9ea6046cf34702dba32eceb212bb/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31312f32382f313637353964643162323461633733643f773d38363926683d33353126663d706e6726733d3331313531
					轻量级锁的加锁过程：
						1.在线程栈中创建一个Lock Record，将其obj（即上图的Object reference）字段指向锁对象。
						2.直接通过CAS指令将Lock Record的地址存储在对象头的mark word中，如果对象处于无锁状态则修改成功，代表该线程获得了轻量级锁。如果失败，进入到步骤3。
						3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置Lock Record第一部分（Displaced Mark Word）为null，起到了一个重入计数器的作用。然后结束。
						4.走到这一步说明发生了竞争，需要膨胀为重量级锁。
					解锁过程：
						1.遍历线程栈,找到所有obj字段等于当前锁对象的Lock Record。
						2.如果Lock Record的Displaced Mark Word为null，代表这是一次重入，将obj设置为null后continue。
						3.如果Lock Record的Displaced Mark Word不为null，则利用CAS指令将对象头的mark word恢复成为Displaced Mark Word。如果成功，则continue，否则膨胀为重量级锁。
	5、什么是自旋锁，偏向锁，轻量级锁，什么叫可重入锁，什么叫公平锁和非公平锁
		a、悲观锁和乐观锁
			乐观锁直到提交时才锁定，所以不会产生任何死锁。
		b、公平锁与非公平锁
			ReentrantLock 提供了公平和非公平锁的实现。
		c、独占锁与共享锁
			独占锁是一种悲观锁，共享锁则是一种乐观锁。
			根据锁只能被单个线程持有还是能被多个线程共同持有，锁可以分为独占锁和共享锁。
			独占锁保证任何时候都只有一个线程能得到锁，ReentrantLock 就是以独占方式实现的。
			共享锁则可以同时由多个线程持有，例如 ReadWriteLock 读写锁，它允许一个资源可以被多线程同时进行读操作。
		d、可重入锁
			当一个线程再次获取它自己己经获取的锁时如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数地进入被该锁锁住的代码。
			实际上， synchronized 内部锁是可重入锁。 可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为 0,说明该锁没有被任何线程占用。 
			当一个钱程获取了该锁时，计数器的值会变成 1 ，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加加 1,
			当释放锁后计数器值减 1。 当计数器值为 0 时，锁里面的线程标示被重置为 null，这时候被阻塞的线程会被唤醒来竞争获取该锁。
		e、自旋锁
			由于 Java 中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。 当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。 
			而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃 CPU 使用权的情况下，
			多次尝试获取（默认次数是 10，可以使用 -XX :PreBlockSpinsh 参数设置该值），很有可能在后面几次尝试中其他线程己经释放了锁。 如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。 
			由此看来自旋锁是使用 CPU 时间换取线程阻塞与调度的开销，但是很有可能这些 CPU 时间白白浪费了。
	6、用过哪些原子类，他们的参数以及原理是什么
	7、cas 是什么，他会产生什么问题（ABA 问题的解决，如加入修改次数、版本号）
	8、如果让你实现一个并发安全的链表，你会怎么做
	9、Fork/Join 框架的理解
		用于并行执行任务的框架，是一个把大任务分割成若干个小任务，最终汇总每个小任务结果后得到大任务结果的框架，这种开发方法也叫分治编程。分治编程可以极大地利用CPU资源，提高任务执行的效率，也是目前与多线程有关的前沿技术。

	10、jdk8 的 parallelStream 的理解
	11、分段锁的原理锁力度减小的思考
	12、CountDownLatch 和 CyclicBarrier 和 Semaphore 的用法，以及相互之间的差别
		一、CountDownLatch：
			场景举例：进行并行查询数据库，返回结果后进行计算，也就是说各个线程要全部运行完毕，才能进行下一步的计算，这时候可以用 CountDownLatch。
				public class ParallelTest {

				    // 此处实现了固定大小的线程池，可根据需要进行其他实现，每次不再新建线程池实例
				    private static ExecutorService executor = Executors.newFixedThreadPool(20);

				    private CountDownLatch countDownLatch;

				    //构造方法参数为并行线程的数量，并且每次new CountDownLatch对象，因为不可重复使用
				    public ParallelTest(Integer nThreads) {
				        this.countDownLatch = new CountDownLatch(nThreads);
				    }

				    public static void main(String[] args) throws Exception {
				        ParallelTest simpleParallelTaskExecutor = new ParallelTest(2);
				        Future<Integer> integerFuture = simpleParallelTaskExecutor.addTask(() -> {
				            //此处模拟执行数据查询等任务
				            Thread.sleep(2000);
				            return 1;
				        });
				        Future<Integer> integerFuture1 = simpleParallelTaskExecutor.addTask(() -> {
				            Thread.sleep(1000);
				            return 2;
				        });
				        simpleParallelTaskExecutor.checkDone(3000);
				        Integer integer = integerFuture.get();
				        Integer integer1 = integerFuture1.get();
				        System.out.println(integer);
				        System.out.println(integer1);
				    }

				    // 调用此方法向线程池中添加任务，此处对 Callable 进行了简单包装，为了执行完任务调用 countDownLatch.countDown();
				    public <V> Future<V> addTask(Callable<V> task) {
				        return executor.submit(new WrapperThread<>(task, countDownLatch));
				    }

				    //可设置超时时间，检查任务是否运行完毕
				    public boolean checkDone(long milliseconds) throws InterruptedException {
				        return countDownLatch.await(milliseconds, TimeUnit.MILLISECONDS);
				    }

				    //Callable包装类，为了执行完任务调用countDownLatch.countDown();
				    public class WrapperThread<V> implements Callable<V> {
				        private Callable<? extends V> callable;
				        private CountDownLatch countDownLatch;

				        public WrapperThread(Callable callable, CountDownLatch countDownLatch) {
				            this.callable = callable;
				            this.countDownLatch = countDownLatch;
				        }

				        @Override
				        public V call() throws Exception {
				            //此处直接调用callable.call();和直接调用thread.run()类似，没有起新的线程此处和加入的任务内部是同一个线程。
				            V call = callable.call();
				            this.countDownLatch.countDown();
				            return call;
				        }
				    }
				}


			https://juejin.im/post/5cccee27e51d453a8f348bb2
			允许一个或多个线程等待其他线程完成操作。
			CountDownLatch如何工作？
				CountDownLatch是通过维护一个计数器 cnt 来实现的，计数器的初始值为线程的数量。每当一个线程完成了自己的任务后，调用 countDown() 方法会让计数器的值就会减1。当计数器值到达0时，
				它表示所有的线程已经完成了任务，那些因为调用 await() 方法而在等待的线程就会被唤醒。
			API：
				countDownLatch.countDown(); // 使CountDownLatch初始值N减1；
				countDownLatch.await(); // 调用该方法的线程等到构造方法传入的N减到0的时候，才能继续往下执行；
				await(long timeout, TimeUnit unit); // 与上面的await方法功能一致，只不过这里有了时间限制，调用该方法的线程等到指定的timeout时间后，不管N是否减至为0，都会继续往下执行；
				long getCount(); // 获取当前CountDownLatch维护的值；
			DEMO：
			public static void main(String[] args) throws InterruptedException {
		        final int totalThread = 10;
		        CountDownLatch countDownLatch = new CountDownLatch(totalThread);
		        ExecutorService executorService = Executors.newCachedThreadPool();
		        for (int i = 0; i < totalThread; i++) {
		            executorService.execute(() -> {
		                System.out.print("run..");
		                countDownLatch.countDown(); // state 为 0时，调用LockSuppor.unpark 唤醒
		            });
		        }
		        countDownLatch.await(); // 新建一个 SHARE 节点入队尾，调用LockSupport.park 挂起
		        System.out.println("end");
		        executorService.shutdown();
		    }

		    流程分析：
			public void countDown() {
				sync.releaseShared(1);// 调用的 AQS 的方法 public final boolean releaseShared(int arg) 如下
			}
			public final boolean releaseShared(int arg) {
		        if (tryReleaseShared(arg)) { // 调用方法如下
		            doReleaseShared(); // 关键是这一步 这是 AQS 中的方法
		            return true;
		        }
		        return false;
		    }
			
			CountDownLatch 内部类 Sync 中的方法：
			protected boolean tryReleaseShared(int releases) {
			    for (;;) {
			      int c = getState();   // 获取当前state属性的值
			      if (c == 0)   // 如果state为0，则说明当前计数器已经计数完成，直接返回
			        return false;
			      int nextc = c-1;
			      if (compareAndSetState(c, nextc)) // 使用CAS算法对state进行设置
			        return nextc == 0;  // 设置成功后返回当前是否为最后一个设置 state 的线程
			    }
			}

			private void doReleaseShared() {
			  for (;;) {
			    Node h = head;  // 记录等待队列中的头结点的线程
			    if (h != null && h != tail) {   // 头结点不为空，且头结点不等于尾节点
			      int ws = h.waitStatus;
			      if (ws == Node.SIGNAL) {  // SIGNAL状态表示当前节点正在等待被唤醒
			        if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))    // 清除当前节点的等待状态
			          continue;
			        unparkSuccessor(h); // 唤醒当前节点的下一个节点
			      } else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
			        continue;
			    }
			    if (h == head)  // 如果h还是指向头结点，说明前面这段代码执行过程中没有其他线程对头结点进行过处理
			      break;
			  }
			}

			private void unparkSuccessor(Node node) {
			  int ws = node.waitStatus;
			  if (ws < 0)
			    compareAndSetWaitStatus(node, ws, 0);   // 清除当前节点的等待状态
			  Node s = node.next;
			  if (s == null || s.waitStatus > 0) {  // s的等待状态大于0说明该节点中的线程已经被外部取消等待了
			    s = null;
			    // 从队列尾部往前遍历，找到最后一个处于等待状态的节点，用s记录下来
			    for (Node t = tail; t != null && t != node; t = t.prev)
			      if (t.waitStatus <= 0)
			        s = t;
			  }
			  if (s != null)
			    LockSupport.unpark(s.thread);   // 唤醒离传入节点最近的处于等待状态的节点线程
			}
			可以看到，unparkSuccessor(Node) 方法的作用是唤醒离传入节点最近的一个处于等待状态的线程，使其继续往下执行。前面我们讲到过，等待队列中的线程可能有多个，而调用 countDown() 方法的线程只唤醒了一个处于等待状态的线程，
			这里剩下的等待线程是如何被唤醒的呢？其实这些线程是被当前唤醒的线程唤醒的。
			具体的我们可以看看 await()方法的具体执行过程。如下是 await()方法的代码：
			public void await() throws InterruptedException {
			  sync.acquireSharedInterruptibly(1);
			}
			await() 方法实际还是调用了 Sync 对象的方法 acquireSharedInterruptibly(int)方法，如下是该方法的具体实现：
			public final void acquireSharedInterruptibly(int arg) throws InterruptedException {
			  if (Thread.interrupted())
			    throw new InterruptedException();
			  if (tryAcquireShared(arg) < 0)
			    doAcquireSharedInterruptibly(arg);
			}
			CountDownLatch 内部类 Sync 中的方法：
			protected int tryAcquireShared(int acquires) {
			    return (getState() == 0) ? 1 : -1;
			}
			可以看到 acquireSharedInterruptibly(int) 方法判断当前线程是否需要以共享状态获取执行权限，这里 tryAcquireShared(int) 方法是 AbstractQueuedSynchronizer 中的一个模板方法，其具体实现在前面的 Sync 类中，
			可以看到，其主要是判断 state 是否为零，如果为零则返回1，表示当前线程不需要进行权限获取，可直接执行后续代码，返回 -1 则表示当前线程需要进行共享权限。
			具体的获取执行权限的代码在 doAcquireSharedInterruptibly(int) 方法中，如下是该方法的具体实现：
			private void doAcquireSharedInterruptibly(int arg) throws InterruptedException {
			  final Node node = addWaiter(Node.SHARED); // 使用当前线程创建一个共享模式的节点
			  boolean failed = true;
			  try {
			    for (;;) {
			      final Node p = node.predecessor();    // 获取当前节点的前一个节点
			      if (p == head) {  // 判断前一个节点是否为头结点
			        int r = tryAcquireShared(arg);  // 查看当前线程是否获取到了执行权限
			        if (r >= 0) {   // 大于0表示获取了执行权限
			          setHeadAndPropagate(node, r); // 将当前节点设置为头结点，并且唤醒后面处于等待状态的节点
			          p.next = null; // help GC
			          failed = false;
			          return;
			        }
			      }
			      // 走到这一步说明没有获取到执行权限，就使当前线程进入“搁置”状态
			      if (shouldParkAfterFailedAcquire(p, node) &&
			          parkAndCheckInterrupt())
			        throw new InterruptedException();
			    }
			  } finally {
			    if (failed)
			      cancelAcquire(node);
			  }
			}
			在 doAcquireSharedInterruptibly(int) 方法中，首先使用当前线程创建一个共享模式的节点。然后在一个 for 循环中判断当前线程是否获取到执行权限，如果有（r >= 0判断）则将当前节点设置为头节点，
			并且唤醒后续处于共享模式的节点；如果没有，则对调用 shouldParkAfterFailedAcquire(Node, Node) 和 parkAndCheckInterrupt() 方法使当前线程处于“搁置”状态，该“搁置”状态是由操作系统进行的，
			这样可以避免该线程无限循环而获取不到执行权限，造成资源浪费，这里也就是线程处于等待状态的位置，也就是说当线程被阻塞的时候就是阻塞在这个位置。当有多个线程调用await()方法而进入等待状态时，
			这几个线程都将等待在此处。这里回过头来看前面的 countDown() 方法，其会唤醒处于等待队列中离头节点最近的一个处于等待状态的线程，也就是说该线程被唤醒之后会继续从这个位置开始往下执行，
			此时执行到 tryAcquireShared(int)方法时，发现 r 大于0（因为 state 已经被置为 0 了），该线程就会调用 setHeadAndPropagate(Node, int) 方法，并且退出当前循环，也就开始执行 awat() 方法之后的代码。
			这里我们看看 setHeadAndPropagate(Node, int) 方法的具体实现：
			private void setHeadAndPropagate(Node node, int propagate) {
			  Node h = head;
			  setHead(node);    // 将当前节点设置为头节点
			  // 检查唤醒过程是否需要往下传递，并且检查头结点的等待状态
			  if (propagate > 0 || h == null || h.waitStatus < 0 ||
			      (h = head) == null || h.waitStatus < 0) {
			    Node s = node.next;
			    if (s == null || s.isShared())  // 如果下一个节点是尝试以共享状态获取获取执行权限的节点，则将其唤醒
			      doReleaseShared();
			  }
			}
			setHeadAndPropagate(Node, int) 方法主要作用是设置当前节点为头结点，并且将唤醒工作往下传递，在传递的过程中，其会判断被传递的节点是否是以共享模式尝试获取执行权限的，
			如果不是，则传递到该节点处为止（一般情况下，等待队列中都只会都是处于共享模式或者处于独占模式的节点）。也就是说，头结点会依次唤醒后续处于共享状态的节点，这也就是共享锁与独占锁的实现方式。
			这里 doReleaseShared() 方法也就是我们前面讲到的会将离头结点最近的一个处于等待状态的节点唤醒的方法。
		二、CyclicBarrier
			https://juejin.im/post/5ae755256fb9a07ac3634067
		三、Semaphore
	异步框架 CompletableFuture：
	ConcurrentHashMap 具体实现及其原理，jdk8 下的改版
====================================================================================================================================================================================
====================================================================================================================================================================================
SpringSpring AOP 与 IOC 的实现原理
	Spring 的 beanFactory 和 factoryBean 的区别。
	为什么 CGlib 方式可以对接口实现代理？
	RMI 与代理模式。
	Spring 的事务隔离级别，实现原理。
	对 Spring 的理解，非单例注入的原理？它的生命周期？循环注入的原理，aop 的实现原理，说说 aop 中的几个术语，它们是怎么相互工作的？
	Mybatis 的底层实现原理。
	MVC 框架原理，他们都是怎么做 url 路由的。
	spring boot 特性，优势，适用场景等。
	quartz 和 timer 对比。
	spring 的 controller 是单例还是多例，怎么保证并发的安全。
分布式相关
	Dubbo 的底层实现原理和机制
	描述一个服务从发布到被消费的详细过程
	分布式系统怎么做服务治理接口的
	幂等性的概念
	消息中间件如何解决消息丢失问题
	Dubbo 的服务请求失败怎么处理
	重连机制会不会造成错误
	对分布式事务的理解
	如何实现负载均衡，有哪些算法可以实现？
	Zookeeper 的用途，选举的原理是什么？
	数据的垂直拆分水平拆分。
	zookeeper 原理和适用场景
	zookeeper watch 机制
	redis/zk 节点宕机如何处理
	分布式集群下如何做到唯一序列号：雪花算法
	如何做一个分布式锁
	用过哪些 MQ，怎么用的，和其他 mq 比较有什么优缺点，MQ 的连接是线程安全的吗
	MQ系统的数据如何保证不丢失
	列举出你能想到的数据库分库分表策略；
	分库分表后，如何解决全表查询的问题。
	nginx upstream 的 failover 机制
算法和数据结构以及设计模式
	海量url去重类问题（布隆过滤器）
	数组和链表数据结构描述，各自的时间复杂度
	二叉树遍历
	快速排序
	BTree相关的操作
	在工作中遇到过哪些设计模式，是如何应用的
	hash 算法的有哪几种，优缺点，使用场景
	什么是一致性 hash
	paxos 算法、Raft 算法
	在装饰器模式和代理模式之间，你如何抉择，请结合自身实际情况聊聊
	代码重构的步骤和原因，如果理解重构到模式？
数据库
	MySQL InnoDB 存储的文件结构
	索引树是如何维护的？
	数据库自增主键可能的问题
	MySQL 的几种优化
	mysql 索引为什么使用B+树
	数据库锁表的相关处理
	索引失效场景
	高并发下如何做到安全的修改同一行数据，乐观锁和悲观锁是什么，INNODB 的行级锁有哪2种，解释其含义
	数据库会死锁吗，举一个死锁的例子，mysql 怎么解决死锁
Redis & 缓存相关
	Redis 的并发竞争问题如何解决了解 Redis 事务的 CAS 操作吗
	缓存机器增删如何对系统影响最小，一致性哈希的实现
	Redis 持久化的几种方式，优缺点是什么，怎么实现的
	Redis 的缓存失效策略
	缓存穿透的解决办法
	redis 集群，高可用，原理
	mySQL 里有 2000w 数据，redis 中只存 20w 的数据，如何保证 redis 中的数据都是热点数据
	用 Redis 和任意语言实现一段恶意登录保护的代码，限制1小时内每用户 Id 最多只能登录5次
	redis 的数据淘汰策略
网络相关
	http1.0 和 http1.1 有什么区别
	TCP/IP 协议
	TCP 三次握手和四次挥手的流程，为什么断开连接要4次,如果握手只有两次，会出现什么
	TIME_WAIT 和 CLOSE_WAIT 的区别
	说说你知道的几种 HTTP 响应码
	当你用浏览器打开一个链接的时候，计算机做了哪些工作步骤
	TCP/IP 如何保证可靠性，数据包有哪些数据组成
	长连接与短连接
	Http 请求 get 和 post 的区别以及数据包格式
	简述 tcp 建立连接3次握手，和断开连接4次握手的过程；
	关闭连接时，出现 TIMEWAIT 过多是由什么原因引起，是出现在主动断开方还是被动断开方。
其他
	maven 解决依赖冲突,快照版和发行版的区别
	Linux 下 IO 模型有几种，各自的含义是什么
	实际场景问题，海量登录日志如何排序和处理SQL操作，主要是索引和聚合函数的应用
	实际场景问题解决，典型的 TOP K 问题
	线上 bug 处理流程
	如何从线上日志发现问题
	linux 利用哪些命令，查找哪里出了问题（例如 io 密集任务，cpu 过度）
	场景问题，有一个第三方接口，有很多个线程去调用获取数据，现在规定每秒钟最多有10个线程同时调用它，如何做到。
	用三个线程按顺序循环打印 abc 三个字母，比如 abcabcabc。
	常见的缓存策略有哪些，你们项目中用到了什么缓存系统，如何设计的
	设计一个秒杀系统，30分钟没付款就自动关闭交易（并发会很高）
	请列出你所了解的性能测试工具
	后台系统怎么防止请求重复提交？