1.索引
数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)的复杂度内获取到相应数据。
创建索引可以大大提高系统的性能。
第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。
第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：
第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。
根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。
唯一索引
唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在employee表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。主键索引数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。聚集索引在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。
如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。
局部性原理与磁盘预读
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。
由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高I/O效率。
预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。
B-/+Tree索引的性能分析
到这里终于可以分析B-/+Tree索引的性能了。
上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析，根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：
每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
B-Tree中一次检索最多需要h-1次I/O（根节点常驻内存），渐进复杂度为O(h)=O(logdN)。一般实际应用中，出度d是非常大的数字，通常超过100，因此h非常小（通常不超过3）。
而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。
综上所述，用B-Tree作为索引结构效率是非常高的。
应该花时间学习B-树和B+树数据结构
=============================================================================================================
1）B树
B树中每个节点包含了键值和键值对于的数据对象存放地址指针，所以成功搜索一个对象可以不用到达树的叶节点。
成功搜索包括节点内搜索和沿某一路径的搜索，成功搜索时间取决于关键码所在的层次以及节点内关键码的数量。
在B树中查找给定关键字的方法是：首先把根结点取来，在根结点所包含的关键字K1,…,kj查找给定的关键字（可用顺序查找或二分查找法），若找到等于给定值的关键字，则查找成功；否则，一定可以确定要查的关键字在某个Ki或Ki+1之间，于是取Pi所指的下一层索引节点块继续查找，直到找到，或指针Pi为空时查找失败。
2）B+树
B+树非叶节点中存放的关键码并不指示数据对象的地址指针，非也节点只是索引部分。所有的叶节点在同一层上，包含了全部关键码和相应数据对象的存放地址指针，且叶节点按关键码从小到大顺序链接。如果实际数据对象按加入的顺序存储而不是按关键码次数存储的话，叶节点的索引必须是稠密索引，若实际数据存储按关键码次序存放的话，叶节点索引时稀疏索引。
B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。
所以 B+树有两种搜索方法：
一种是按叶节点自己拉起的链表顺序搜索。
一种是从根节点开始搜索，和B树类似，不过如果非叶节点的关键码等于给定值，搜索并不停止，而是继续沿右指针，一直查到叶节点上的关键码。所以无论搜索是否成功，都将走完树的所有层。
B+ 树中，数据对象的插入和删除仅在叶节点上进行。
这两种处理索引的数据结构的不同之处：
a，B树中同一键值不会出现多次，并且它有可能出现在叶结点，也有可能出现在非叶结点中。而B+树的键一定会出现在叶结点中，并且有可能在非叶结点中也有可能重复出现，以维持B+树的平衡。
b，因为B树键位置不定，且在整个树结构中只出现一次，虽然可以节省存储空间，但使得在插入、删除操作复杂度明显增加。B+树相比来说是一种较好的折中。
c，B树的查询效率与键在树中的位置有关，最大时间复杂度与B+树相同(在叶结点的时候)，最小时间复杂度为1(在根结点的时候)。而B+树的时候复杂度对某建成的树是固定的。
2.数据库分库分表策略
一、背景：
系统刚开始的时候，数据库都是单库单表结构。随着业务量的增加进行第一次数据库升级，根据业务垂直拆分数据库，这样多变成多个业务数据库，每个数据库里面还是单表结构。接下来，继续随着业务量的继续增加，单表已经很难承受数据量，就要进行分表，这个时候就是，多个业务库，每个业务库下对需要分表的表进行分表。再接下来，随着应用的增加，数据库IO，磁盘等等都抗不住了，就要把分表的表分到多个库，这样就形成了如下的结构。 
重点：本文主要讨论的是分库分表的策略，也就是分库分表的规则或者说是算法。
二、分库分表的依据--分库分表字段的选择
分库分表首先要确定根据哪个字段、或者哪几个字段进行路由，一般的原则是按使用频率最高维度的字段去分库分表，尽量保证高使用维度下只查询单表。
常用的字段有主键ID，用户ID，时间，商户ID，产品ID，业务类型等等
三、分库分表策略
主要原理：分区、取模、数据路由表
1. 按照时间区间
1）基本原理：
一定区间内时间产生的数据放到一张表里面，多个时间区间的表放到一个库里面
2）简单例子：
单库多表结构，按月分表可以这样，user_201601,user_201602,...,user_201612这种结构。按年分表可以这样，user_2016,user_2017,...这种。
3）多库多表算法：
比如按天分表，每天一张表，当单库超过100张表的时候，进行分库到下一张表。那么假如第一张报表在库BD0，表名是user_20160201。从DB0.user_20160201，..到DB0.user_20160511就100张表了，接下来就要进行分库了，进入20160512，就是DB1.user_20160512，这个算法就是上线的时候定一个上线日期，具体算法如下
库ID = （当前日期 - 上线日期）/ 100
表ID = user_yyyyMMdd
注：好处是可以直接根据时间经过简单计算定位到哪个库和哪个表
还有一种算法：
库ID = （当前日期 - 上线日期）/ 100
表ID = (当前日期 - 上线日期) % 100
表名如下： DB0.user_0001, user_0002,....,user_01000。
注：表名和库名都要经过计算，比较麻烦
4）按月分表，每个月一张表；这种情况，一般就不用分库了，一年12张表说明量也不会特别大，如果量特别大，或者是热点数据，可以一年分一个库，具体算法和上面差不多。
5）按季度分表，基本不用分库。
6）按年分表，肯定不用分库了，没有必要了。
2. 按照主键ID区间
对于自增的主键ID，可以按照ID区间进行分表，以1000万数据量为分界线，对线性的ID进行切割分表，每涨到1000万数据，分到下一张表，超过一定数目的表，进行分库。
库ID = 主键ID / 1000万 / 100
表ID = 主键ID / 1000万 % 100
如：DB0.user_0000,...,DB0.user_0099, DB1.user_0000,...,DB1.user_0099
3. 按照指定字段hash后再取模
如果要取模的字段不是整数型，要先hash后，再通过取模算法，算出在哪个库和那个表。具体算法，参照下面的按用户ID取模。
4. 按照用户ID取模
这里把按照用户ID取模单独拎出来，因为就使用而言，是使用场景最多的情况，很多时候都是用户相关数据量最大，需要分库分表，查询维度更多也是按照用户来查询，所以对用户取模，让同一个用户的数据落到一张表里面，再好不过了。
案例：假设用户ID是整数型的。库数量要分4库，每个库表数量8表，一共32张表。
原理讲解：
一共要分4库，8表，共32张表，也就是1到32的用户ID要平均分配到每张表应该有一条数据，这样就有两种分法。
1） 1到8是第一个库，9到16第二个库，17到24第三个库，25到32是第四个库，每个库里面表的编号都是0到3，这个原则是一个库里面一个一个分，分完再下一个库一个一个分，保证不重复，不漏掉。
2）1,5,9这样每隔4个一个库，2开头隔4个一个库，这个原则是一个库分一个，在分下一个库，一圈走完，再在第一库没分到的表继续分，也保证了不重复，不漏掉原则。
库ID = userId % 库数量4
表ID = userId / 库数量4 % 表数量8
或者
库ID = userId / 表数量4 % 库数量4
表ID = userId % 表数量8
算法图示如下： 
5. 数据路由表
如果分库分表的算法很复杂，可以通过路由表+程序算法，来存储和计算分库分表规则，不过一般不建议，分库分表搞得太复杂，不便于维护和查询问题
四、各个方案对比
分区算法
优点：线性扩容，平滑扩容，不需要数据迁移
缺点：存在热点数据，非时间维度查询多的情况，聚合复杂
建议：冷数据，用户维度查询少，且数据量大的情况用分区算法
取模算法
优点：同一个热点的数据可以做到一个表里面，查询方便
缺点：扩容不是很方便，需要数据迁移
建议：用户维度查询多，热点维度查询多的情况，建议使用
注：
分库分表的核心是未来数据量的预估，根据预估和实际使用情况来确定分库分表方案，一般像订单类数据以用户维度取模分表最好，商品数据以商户取模最好，签到等活动流水数据时间分区最好。
取模方案扩容的解决：一、可以提前按照预估方案创建库和表，前期放到一个DB，后期迁移，或者一次性弄好 二、可以按照预估的方案去确定分库和分表的后缀ID，但是前期只创建一部分库和表。例如：最终4库，每个库16个表。后缀应该是0000----0315共64个表的后缀，前期可以一个库，4个表，也就是所有数据都在这个四张表里面。
0000--0003-----》0000表
0100--0103-----》0000表
0200--0203-----》0000表
0300--0303-----》0000表
0004--0007-----》0004表
0104--0107-----》0004表
0204--0207-----》0004表
0304--0307-----》0004表
0008--0011-----》0008表
0108--0111-----》0008表
0208--0211-----》0008表
0308--0311-----》0008表
0012--0015-----》0012表
0112--0115-----》0012表
0212--0215-----》0012表
0312--0315-----》0012表
后续可以二分法，迁移数据，扩容。
3.回调模式
回调函数，第一次见是在Java编程思想中，以及后来的观察者模式也应用了回调函数的思想。但是一直都没有重视，终于在一次面试的时候吃亏了，越来越理解为什么很多人说Java编程思想这本书要一遍遍的看，吃透！
首先在网络上搜索很多文章介绍什么是回调函数，看的云里雾里的。后来自己一步步分解终于理解了，记录如下。
从维基百科上面摘抄定义：（看完本篇文章再来理解这个定义）
在计算机程序设计中，回调函数，或简称回调，是指通过函数参数传递到其它代码的，某一块可执行代码的引用。这一设计允许了底层代码调用在高层定义的子程序。
在Java里面，我们使用接口来实现回调。
这篇文章中的解说定义非常好：http://blog.csdn.net/sweetwxh/article/details/2067139
所谓的回调，就是程序员A写了一段程序（程序a），其中预留有回调函数接口，并封装好了该程序。程序员B要让a调用自己的程序b中的一个方法，于是，他通过a中的接口回调自己b中的方法。下面是例子。
1. 首先定义一个类Caller，按照上面的定义就是程序员A写的程序a，这个类里面保存一个接口引用。
[java] view plain copy
- public class Caller {
- private MyCallInterface callInterface;
- public Caller() {
- }
- public void setCallFunc(MyCallInterface callInterface) {
- this.callInterface = callInterface;
- }
- public void call() {
- callInterface.printName();
- }
- }
2. 当然需要接口的定义，为了方便程序员B根据我的定义编写程序实现接口。
[java] view plain copy
- public interface MyCallInterface {
- public void printName();
- }
3. 第三是定义程序员B写的程序b
[java] view plain copy
- public class Client implements MyCallInterface {
- @Override
- public void printName() {
- System.out.println("This is the client printName method");
- }
- }
4. 测试如下
[java] view plain copy
- public class Test {
- public static void main(String[] args) {
- Caller caller = new Caller();
- caller.setCallFunc(new Client());
- caller.call();
- }
- }
看到这里应该明白什么是回调了，有些文章介绍的很好，但是刚开始没看明白，是因为把第3步的类省略，直接写成匿名类了。
5. 在测试方法中直接使用匿名类，省去第3步。
[java] view plain copy
- public class Test {
- public static void main(String[] args) {
- Caller caller = new Caller();
- // caller.setCallFunc(new Client());
- caller.setCallFunc(new MyCallInterface() {
- public void printName() {
- System.out.println("This is the client printName method");
- }
- });
- caller.call();
- }
- }
看完了上面的文章，直接看下面这篇文章：http://kidult.iteye.com/blog/148982
以上就是回调函数的全部理解
4.线程安全
那怎么才能实现线程安全呢？Java给我们提供了哪些机制？
想要实现线程安全大致有三种方法：
- 不适用单例模式，而是用多实例。
- 使用锁机制Synchronized、lock方式。
- 使用java.util.concurrent下面的类库。
java中线程安全的类：
-
通过
synchronized关键字给方法加上内置锁来实现线程安全Timer，TimerTask，Vector，Stack，HashTable，StringBuffer -
原子类
Atomicxxx—包装类的线程安全类
如AtomicLong，AtomicInteger等等Atomicxxx是通过Unsafe类的native方法实现线程安全的 -
BlockingQueue和BlockingDequeBlockingDeque接口继承了BlockingQueue接口，BlockingQueue接口的实现类有ArrayBlockingQueue，LinkedBlockingQueue，PriorityBlockingQueue而BlockingDeque接口的实现类有LinkedBlockingDequeBlockingQueue和BlockingDeque都是通过使用定义为final的ReentrantLock作为类属性显式加锁实现同步的 -
CopyOnWriteArrayList和CopyOnWriteArraySetCopyOnWriteArraySet的内部实现是在其类内部声明一个final的CopyOnWriteArrayList属性，并在调用其构造函数时实例化该CopyOnWriteArrayList，CopyOnWriteArrayList采用的是显式地加上ReentrantLock实现同步，而CopyOnWriteArrayList容器的线程安全性在于在每次修改时都会创建并重新发布一个新的容器副本，从而实现可变性。 -
Concurrentxxx
最常用的就是ConcurrentHashMap，当然还有ConcurrentSkipListSet和ConcurrentSkipListMap等等。ConcurrentHashMap使用了一种完全不同的加锁策略来提供更高的并发性和伸缩性。ConcurrentHashMap并不是将每个方法都在同一个锁上同步并使得每次只能有一个线程访问容器，而是使用一种粒度更细的加锁机制——分段锁来实现更大程度的共享
在这种机制中，任意数量的读取线程可以并发访问Map，执行读取操作的线程和执行写入操作的线程可以并发地访问Map，并且一定数量的写入线程可以并发地修改Map，这使得在并发环境下吞吐量更高，而在单线程环境中只损失非常小的性能 -
ThreadPoolExecutorThreadPoolExecutor也是使用了ReentrantLock显式加锁同步 -
Collections中的synchronizedCollection(Collection c)方法可将一个集合变为线程安全，其内部通过synchronized关键字加锁同步
5.生产者消费者模式
在实际的软件开发过程中，经常会碰到如下场景：
- 某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。
- 产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。
- 单单抽象出生产者和消费者，还够不上是生产者／消费者模式。
- 该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。
-
生产者把数据放入缓冲区，而消费者从缓冲区取出数据。
大概的结构如下图。
比较直白的一个寄信的例子:
1、你把信写好——相当于生产者制造数据
2、你把信放入邮筒——相当于生产者把数据放入缓冲区
3、邮递员把信从邮筒取出——相当于消费者把数据取出缓冲区
4、邮递员把信拿去邮局做相应的处理——相当于消费者处理数据
- 优点
可能会有这样的疑问：这个缓冲区有什么用？为什么不让生产者直接调用消费者的某个函数，直接把数据传递过去？搞出这么一个缓冲区干什么？
其实这里面是大有讲究的，大概有如下一些好处。
解耦
- 假设生产者和消费者分别是两个类。
- 如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。
- 将来如果消费者的代码发生变化，可能会影响到生产者。
- 而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
接着上述的例子，如果不使用邮筒（也就是缓冲区），你必须得把信直接交给邮递员。有同学会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须得认识谁是邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。这就产生和你和邮递员之间的依赖（相当于生产者和消费者的强耦合）。万一哪天邮递员换人了，你还要重新认识一下（相当于消费者变化导致修改生产者代码）。而邮筒相对来说比较固定，你依赖它的成本就比较低（相当于和缓冲区之间的弱耦合）。
支持并发（concurrency）
-
生产者直接调用消费者的某个方法，还有另一个弊端。
-
由于函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回之前，生产者只好一直等在那边。万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。
-
使用了生产者／消费者模式之后，生产者和消费者可以是两个独立的并发主体（常见并发类型有进程和线程两种，后面的帖子会讲两种并发类型下的应用）。生产者把制造出来的数据往缓冲区一丢，就可以再去生产下一个数据。基本上不用依赖消费者的处理速度。
其实当初这个模式，主要就是用来处理并发问题的。
从寄信的例子来看。如果没有邮筒，你得拿着信傻站在路口等邮递员过来收（相当于生产者阻塞）；又或者邮递员得挨家挨户问，谁要寄信（相当于消费者轮询）。不管是哪种方法，都挺土的。
◇支持忙闲不均
缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。等生产者的制造速度慢下来，消费者再慢慢处理掉。
为了充分复用，我们再拿寄信的例子来说事。假设邮递员一次只能带走1000封信。万一某次碰上情人节（也可能是圣诞节）送贺卡，需要寄出去的信超过1000封，这时候邮筒这个缓冲区就派上用场了。邮递员把来不及带走的信暂存在邮筒中，等下次过来时再拿走。
费了这么多口水，希望原先不太了解生产者／消费者模式的同学能够明白它是怎么一回事。然后在下一个帖子中，我们来说说如何确定数据单元。
另外，为了方便阅读，把本系列帖子的目录整理如下：
1、如何确定数据单元
2、队列缓冲区
3、队列缓冲区
4、双缓冲区
5、......
[1]：如何确定数据单元？
既然前一个帖子已经搞过扫盲了，那接下来应该开始聊一些具体的编程技术问题了。不过在进入具体的技术细节之前，咱们先要搞明白一个问题：如何确定数据单元？只有把数据单元分析清楚，后面的技术设计才好搞。
★啥是数据单元
何谓数据单元捏？简单地说，每次生产者放到缓冲区的，就是一个数据单元；每次消费者从缓冲区取出的，也是一个数据单元。对于前一个帖子中寄信的例子，我们可以把每一封单独的信件看成是一个数据单元。
不过光这么介绍，太过于简单，无助于大伙儿分析出这玩意儿。所以，后面咱们来看一下数据单元需要具备哪些特性。搞明白这些特性之后，就容易从复杂的业务逻辑中分析出适合做数据单元的东西了。
★数据单元的特性
分析数据单元，需要考虑如下几个方面的特性：
◇关联到业务对象
首先，数据单元必须关联到某种业务对象。在考虑该问题的时候，你必须深刻理解当前这个生产者／消费者模式所对应的业务逻辑，才能够作出合适的判断。
由于“寄信”这个业务逻辑比较简单，所以大伙儿很容易就可以判断出数据单元是啥。但现实生活中，往往没这么乐观。大多数业务逻辑都比较复杂，当中包含的业务对象是层次繁多、类型各异。在这种情况下，就不易作出决策了。
这一步很重要，如果选错了业务对象，会导致后续程序设计和编码实现的复杂度大为上升，增加了开发和维护成本。
◇完整性
所谓完整性，就是在传输过程中，要保证该数据单元的完整。要么整个数据单元被传递到消费者，要么完全没有传递到消费者。不允许出现部分传递的情形。
对于寄信来说，你不能把半封信放入邮筒；同样的，邮递员从邮筒中拿信，也不能只拿出信的一部分。
◇独立性
所谓独立性，就是各个数据单元之间没有互相依赖，某个数据单元传输失败不应该影响已经完成传输的单元；也不应该影响尚未传输的单元。
为啥会出现传输失败捏？假如生产者的生产速度在一段时间内一直超过消费者的处理速度，那就会导致缓冲区不断增长并达到上限，之后的数据单元就会被丢弃。如果数据单元相互独立，等到生产者的速度降下来之后，后续的数据单元继续处理，不会受到牵连；反之，如果数据单元之间有某种耦合，导致被丢弃的数据单元会影响到后续其它单元的处理，那就会使程序逻辑变得非常复杂。
对于寄信来说，某封信弄丢了，不会影响后续信件的送达；当然更不会影响已经送达的信件。
◇颗粒度
前面提到，数据单元需要关联到某种业务对象。那么数据单元和业务对象是否要一一对应捏？很多场合确实是一一对应的。
不过，有时出于性能等因素的考虑，也可能会把N个业务对象打包成一个数据单元。那么，这个N该如何取值就是颗粒度的考虑了。颗粒度的大小是有讲究的。太大的颗粒度可能会造成某种浪费；太小的颗粒度可能会造成性能问题。颗粒度的权衡要基于多方面的因素，以及一些经验值的考量。
还是拿寄信的例子。如果颗粒度过小（比如设定为1），那邮递员每次只取出1封信。如果信件多了，那就得来回跑好多趟，浪费了时间。
如果颗粒度太大（比如设定为100），那寄信的人得等到凑满100封信才拿去放入邮筒。假如平时很少写信，就得等上很久，也不太爽。
可能有同学会问：生产者和消费者的颗粒度能否设置成不同大小（比如对于寄信人设置成1，对于邮递员设置成100）。当然，理论上可以这么干，但是在某些情况下会增加程序逻辑和代码实现的复杂度。后面讨论具体技术细节时，或许会聊到这个问题。
好，数据单元的话题就说到这。希望通过本帖子，大伙儿能够搞明白数据单元到底是怎么一回事。下一个帖子，咱们来聊一下“基于队列的缓冲区”，技术上如何实现。
[2]：队列缓冲区
经过前面两个帖子的铺垫，今天终于开始聊一些具体的编程技术了。由于不同的缓冲区类型、不同的并发场景对于具体的技术实现有较大的影响。为了深入浅出、便于大伙儿理解，咱们先来介绍最传统、最常见的方式。也就是单个生产者对应单个消费者，当中用队列（FIFO）作缓冲。
关于并发的场景，在之前的帖子“进程还线程？是一个问题！”中，已经专门论述了进程和线程各自的优缺点，两者皆不可偏废。所以，后面对各种缓冲区类型的介绍都会同时提及进程方式和线程方式。
★线程方式
先来说一下并发线程中使用队列的例子，以及相关的优缺点。
◇内存分配的性能
在线程方式下，生产者和消费者各自是一个线程。生产者把数据写入队列头（以下简称push），消费者从队列尾部读出数据（以下简称pop）。当队列为空，消费者就稍息（稍事休息）；当队列满（达到最大长度），生产者就稍息。整个流程并不复杂。
那么，上述过程会有什么问题捏？一个主要的问题是关于内存分配的性能开销。对于常见的队列实现：在每次push时，可能涉及到堆内存的分配；在每次pop时，可能涉及堆内存的释放。假如生产者和消费者都很勤快，频繁地push、pop，那内存分配的开销就很可观了。对于内存分配的开销，用Java的同学可以参见前几天的帖子“Java性能优化[1]”；对于用C/C++的同学，想必对OS底层机制会更清楚，应该知道分配堆内存（new或malloc）会有加锁的开销和用户态／核心态切换的开销。
那该怎么办捏？请听下文分解，关于“生产者／消费者模式[3]：环形缓冲区”。
◇同步和互斥的性能
另外，由于两个线程共用一个队列，自然就会涉及到线程间诸如同步啊、互斥啊、死锁啊等等劳心费神的事情。好在"操作系统"这门课程对此有详细介绍，学过的同学应该还有点印象吧？对于没学过这门课的同学，也不必难过，网上相关的介绍挺多的（比如"这里"），大伙自己去瞅一瞅。关于这方面的细节，咱今天就不多啰嗦了。
这会儿要细谈的是，同步和互斥的性能开销。在很多场合中，诸如信号量、互斥量等玩意儿的使用也是有不小的开销的（某些情况下，也可能导致用户态／核心态切换）。如果像刚才所说，生产者和消费者都很勤快，那这些开销也不容小觑啊。
这又该咋办捏？请听下文的下文分解，关于“生产者／消费者模式[4]：双缓冲区”。
◇适用于队列的场合
刚才尽批判了队列的缺点，难道队列方式就一无是处？非也。由于队列是很常见的数据结构，大部分编程语言都内置了队列的支持（具体介绍见"这里"），有些语言甚至提供了线程安全的队列（比如JDK 1.5引入的ArrayBlockingQueue）。因此，开发人员可以捡现成，避免了重新发明轮子。
所以，假如你的数据流量不是很大，采用队列缓冲区的好处还是很明显的：逻辑清晰、代码简单、维护方便。比较符合KISS原则。
★进程方式
说完了线程的方式，再来介绍基于进程的并发。
跨进程的生产者／消费者模式，非常依赖于具体的进程间通讯（IPC）方式。而IPC的种类名目繁多，不便于挨个列举（毕竟口水有限）。因此咱们挑选几种跨平台、且编程语言支持较多的IPC方式来说事儿。
◇匿名管道
感觉管道是最像队列的IPC类型。生产者进程在管道的写端放入数据；消费者进程在管道的读端取出数据。整个的效果和线程中使用队列非常类似，区别在于使用管道就无需操心线程安全、内存分配等琐事（操作系统暗中都帮你搞定了）。
管道又分命名管道和匿名管道两种，今天主要聊匿名管道。因为命名管道在不同的操作系统下差异较大（比如Win32和POSIX，在命名管道的API接口和功能实现上都有较大差异；有些平台不支持命名管道，比如Windows CE）。除了操作系统的问题，对于有些编程语言（比如Java）来说，命名管道是无法使用的。所以我一般不推荐使用这玩意儿。
其实匿名管道在不同平台上的API接口，也是有差异的（比如Win32的CreatePipe和POSIX的pipe，用法就很不一样）。但是我们可以仅使用标准输入和标准输出（以下简称stdio）来进行数据的流入流出。然后利用shell的管道符把生产者进程和消费者进程关联起来（没听说过这种手法的同学，可以看"这里"）。实际上，很多操作系统（尤其是POSIX风格的）自带的命令都充分利用了这个特性来实现数据的传输（比如more、grep等）。
这么干有几个好处：
1、基本上所有操作系统都支持在shell方式下使用管道符。因此很容易实现跨平台。
2、大部分编程语言都能够操作stdio，因此跨编程语言也就容易实现。
3、刚才已经提到，管道方式省却了线程安全方面的琐事。有利于降低开发、调试成本。
当然，这种方式也有自身的缺点：
1、生产者进程和消费者进程必须得在同一台主机上，无法跨机器通讯。这个缺点比较明显。
2、在一对一的情况下，这种方式挺合用。但如果要扩展到一对多或者多对一，那就有点棘手了。所以这种方式的扩展性要打个折扣。假如今后要考虑类似的扩展，这个缺点就比较明显。
3、由于管道是shell创建的，对于两边的进程不可见（程序看到的只是stdio）。在某些情况下，导致程序不便于对管道进行操纵（比如调整管道缓冲区尺寸）。这个缺点不太明显。
4、最后，这种方式只能单向传数据。好在大多数情况下，消费者进程不需要传数据给生产者进程。万一你确实需要信息反馈（从消费者到生产者），那就费劲了。可能得考虑换种IPC方式。
顺便补充几个注意事项，大伙儿留意一下：
1、对stdio进行读写操作是以阻塞方式进行。比如管道中没有数据，消费者进程的读操作就会一直停在哪儿，直到管道中重新有数据。
2、由于stdio内部带有自己的缓冲区（这缓冲区和管道缓冲区是两码事），有时会导致一些不太爽的现象（比如生产者进程输出了数据，但消费者进程没有立即读到）。具体的细节，大伙儿可以看"这里"。
◇SOCKET（TCP方式）
基于TCP方式的SOCKET通讯是又一个类似于队列的IPC方式。它同样保证了数据的顺序到达；同样有缓冲的机制。而且这玩意儿也是跨平台和跨语言的，和刚才介绍的shell管道符方式类似。
SOCKET相比shell管道符的方式，有啥优点捏？主要有如下几个优点：
1、SOCKET方式可以跨机器（便于实现分布式）。这是主要优点。
2、SOCKET方式便于将来扩展成为多对一或者一对多。这也是主要优点。
3、SOCKET可以设置阻塞和非阻塞方法，用起来比较灵活。这是次要优点。
4、SOCKET支持双向通讯，有利于消费者反馈信息。
当然有利就有弊。相对于上述shell管道的方式，使用SOCKET在编程上会更复杂一些。好在前人已经做了大量的工作，搞出很多SOCKET通讯库和框架给大伙儿用（比如C++的ACE库、Python的Twisted）。借助于这些第三方的库和框架，SOCKET方式用起来还是比较爽的。由于具体的网络通讯库该怎么用不是本系列的重点，此处就不细说了。
虽然TCP在很多方面比UDP可靠，但鉴于跨机器通讯先天的不可预料性（比如网线可能被某傻X给拔错了，网络的忙闲波动可能很大），在程序设计上我们还是要多留一手。具体该如何做捏？可以在生产者进程和消费者进程内部各自再引入基于线程的"生产者／消费者模式"。这话听着像绕口令，为了便于理解，画张图给大伙儿瞅一瞅。
架构设计：生产者/消费者模式
这么做的关键点在于把代码分为两部分：生产线程和消费线程属于和业务逻辑相关的代码（和通讯逻辑无关）；发送线程和接收线程属于通讯相关的代码（和业务逻辑无关）。
这样的好处是很明显的，具体如下：
1、能够应对暂时性的网络故障。并且在网络故障解除后，能够继续工作。
2、网络故障的应对处理方式（比如断开后的尝试重连），只影响发送和接收线程，不会影响生产线程和消费线程（业务逻辑部分）。
3、具体的SOCKET方式（阻塞和非阻塞）只影响发送和接收线程，不影响生产线程和消费线程（业务逻辑部分）。
4、不依赖TCP自身的发送缓冲区和接收缓冲区。（默认的TCP缓冲区的大小可能无法满足实际要求）
5、业务逻辑的变化（比如业务需求变更）不影响发送线程和接收线程。
针对上述的最后一条，再多啰嗦几句。如果整个业务系统中有多个进程是采用上述的模式，那或许可以重构一把：在业务逻辑代码和通讯逻辑代码之间切一刀，把业务逻辑无关的部分封装成一个通讯中间件（说中间件显得比较牛X :-）。如果大伙儿对这玩意儿有兴趣，以后专门开个帖子聊。
[3]：环形缓冲区
前一个帖子提及了队列缓冲区可能存在的性能问题及解决方法：环形缓冲区。今天就专门来描述一下这个话题。
为了防止有人给咱扣上“过度设计”的大帽子，事先声明一下：只有当存储空间的分配／释放非常频繁并且确实产生了明显的影响，你才应该考虑环形缓冲区的使用。否则的话，还是老老实实用最基本、最简单的队列缓冲区吧。还有一点需要说明一下：本文所提及的“存储空间”，不仅包括内存，还可能包括诸如硬盘之类的存储介质。
★环形缓冲区 vs 队列缓冲区
◇外部接口相似
在介绍环形缓冲区之前，咱们先来回顾一下普通的队列。普通的队列有一个写入端和一个读出端。队列为空的时候，读出端无法读取数据；当队列满（达到最大尺寸）时，写入端无法写入数据。
对于使用者来讲，环形缓冲区和队列缓冲区是一样的。它也有一个写入端（用于push）和一个读出端（用于pop），也有缓冲区“满”和“空”的状态。所以，从队列缓冲区切换到环形缓冲区，对于使用者来说能比较平滑地过渡。
◇内部结构迥异
虽然两者的对外接口差不多，但是内部结构和运作机制有很大差别。队列的内部结构此处就不多啰嗦了。重点介绍一下环形缓冲区的内部结构。
大伙儿可以把环形缓冲区的读出端（以下简称R）和写入端（以下简称W）想象成是两个人在体育场跑道上追逐（R追W）。当R追上W的时候，就是缓冲区为空；当W追上R的时候（W比R多跑一圈），就是缓冲区满。
为了形象起见，去找来一张图并略作修改，如下：
架构设计：生产者/消费者模式
从上图可以看出，环形缓冲区所有的push和pop操作都是在一个固定的存储空间内进行。而队列缓冲区在push的时候，可能会分配存储空间用于存储新元素；在pop时，可能会释放废弃元素的存储空间。所以环形方式相比队列方式，少掉了对于缓冲区元素所用存储空间的分配、释放。这是环形缓冲区的一个主要优势。
★环形缓冲区的实现
如果你手头已经有现成的环形缓冲区可供使用，并且你对环形缓冲区的内部实现不感兴趣，可以跳过这段。
◇数组方式 vs 链表方式
环形缓冲区的内部实现，即可基于数组（此处的数组，泛指连续存储空间）实现，也可基于链表实现。
数组在物理存储上是一维的连续线性结构，可以在初始化时，把存储空间一次性分配好，这是数组方式的优点。但是要使用数组来模拟环，你必须在逻辑上把数组的头和尾相连。在顺序遍历数组时，对尾部元素（最后一个元素）要作一下特殊处理。访问尾部元素的下一个元素时，要重新回到头部元素（第0个元素）。如下图所示：
架构设计：生产者/消费者模式
使用链表的方式，正好和数组相反：链表省去了头尾相连的特殊处理。但是链表在初始化的时候比较繁琐，而且在有些场合（比如后面提到的跨进程的IPC）不太方便使用。
◇读写操作
环形缓冲区要维护两个索引，分别对应写入端（W）和读取端（R）。写入（push）的时候，先确保环没满，然后把数据复制到W所对应的元素，最后W指向下一个元素；读取（pop）的时候，先确保环没空，然后返回R对应的元素，最后R指向下一个元素。
◇判断“空”和“满”
上述的操作并不复杂，不过有一个小小的麻烦：空环和满环的时候，R和W都指向同一个位置！这样就无法判断到底是“空”还是“满”。大体上有两种方法可以解决该问题。
办法1：始终保持一个元素不用
当空环的时候，R和W重叠。当W比R跑得快，追到距离R还有一个元素间隔的时候，就认为环已经满。当环内元素占用的存储空间较大的时候，这种办法显得很土（浪费空间）。
办法2：维护额外变量
如果不喜欢上述办法，还可以采用额外的变量来解决。比如可以用一个整数记录当前环中已经保存的元素个数（该整数>=0）。当R和W重叠的时候，通过该变量就可以知道是“空”还是“满”。
◇元素的存储
由于环形缓冲区本身就是要降低存储空间分配的开销，因此缓冲区中元素的类型要选好。尽量存储值类型的数据，而不要存储指针（引用）类型的数据。因为指针类型的数据又会引起存储空间（比如堆内存）的分配和释放，使得环形缓冲区的效果打折扣。
★应用场合
刚才介绍了环形缓冲区内部的实现机制。按照前一个帖子的惯例，我们来介绍一下在线程和进程方式下的使用。
如果你所使用的编程语言和开发库中带有现成的、成熟的环形缓冲区，强烈建议使用现成的库，不要重新制造轮子；确实找不到现成的，才考虑自己实现。如果你纯粹是业余时间练练手，那另当别论。
◇用于并发线程
和线程中的队列缓冲区类似，线程中的环形缓冲区也要考虑线程安全的问题。除非你使用的环形缓冲区的库已经帮你实现了线程安全，否则你还是得自己动手搞定。线程方式下的环形缓冲区用得比较多，相关的网上资料也多，下面就大致介绍几个。
对于C++的程序员，强烈推荐使用boost提供的circular_buffer模板，该模板最开始是在boost 1.35版本中引入的。鉴于boost在C++社区中的地位，大伙儿应该可以放心使用该模板。
对于C程序员，可以去看看开源项目circbuf，不过该项目是GPL协议的，不太爽；而且活跃度不太高；而且只有一个开发人员。大伙儿慎用！建议只拿它当参考。
对于C#程序员，可以参考CodeProject上的一个示例。
◇用于并发进程
进程间的环形缓冲区，似乎少有现成的库可用。大伙儿只好自己动手、丰衣足食了。
适用于进程间环形缓冲的IPC类型，常见的有共享内存和文件。在这两种方式上进行环形缓冲，通常都采用数组的方式实现。程序事先分配好一个固定长度的存储空间，然后具体的读写操作、判断“空”和“满”、元素存储等细节就可参照前面所说的来进行。
共享内存方式的性能很好，适用于数据流量很大的场景。但是有些语言（比如Java）对于共享内存不支持。因此，该方式在多语言协同开发的系统中，会有一定的局限性。
6.concurrenthashmap1.7 和 1.8的不同
- JDK1.8取消了segment数组，直接用table保存数据，锁的粒度更小，减少并发冲突的概率。
- JDK1.8存储数据时采用了链表+红黑树的形式，纯链表的形式时间复杂度为O(n)，红黑树则为O（logn），性能提升很大。什么时候链表转红黑树？当key值相等的元素形成的链表中元素个数超过8个的时候。
- JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
- JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
- JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
- JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点
- 因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
- JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
- 在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据
7.DNS是用TCP还是UDP？
DNS占用53号端口，同时使用TCP和UDP协议。那么DNS在什么情况下使用这两种协议？
DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议。
DNS区域传输的时候使用TCP协议：
1.辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
2.TCP是一种可靠连接，保证了数据的准确性。
域名解析时使用UDP协议：
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
8.JUC包下常用的类
这篇文章主要是关于java.util.concurrent类包下的常用类，会给出相应的介绍并给出实例。
JUC是JDK5才引入的并发类库。它的基础就是AbstractQueuedSynchronizer抽象类，Lock，CountDownLatch等的基础就是该类，而该类又用到了CAS操作。CAS之前已经介绍过。JUC在同步器的设计上有获取操作和释放操作。AbstractQueuedSynchronizer（AQS）就是一种同步器的实现。
需要满足以上两个操作，需要以下3点来支持：
1、原子操作同步状态：CAS操作是原子的，进行状态量的改变。
2、阻塞或者唤醒一个线程：通过LockSupport.park阻塞线程，LockSupport.unpark唤醒线程，它们都是用到Native方法调用底层。
3、内部应该维护一个队列：采用CLH（三个人名）队列，Node节点，而线程Thread为Node节点的一个元素。
1.CountDownLatch
这个类是一个同步计数器，主要用于线程间的控制，当CountDownLatch的count计数>0时，await()会造成阻塞，直到count变为0，await()结束阻塞，使用countDown()会让count减1。CountDownLatch的构造函数可以设置count值，当count=1时，它的作用类似于wait()和notify()的作用。如果我想让其他线程执行完指定程序，其他所有程序都执行结束后我再执行，这时可以用CountDownLatch，但计数无法被重置，如果需要重置计数，请考虑使用 CyclicBarrier 。例子：
-
import java.util.concurrent.CountDownLatch; -
public class cD implements Runnable{ -
private CountDownLatch begin ; -
private CountDownLatch end; -
private int s; -
public cD(CountDownLatch begin,CountDownLatch end){ -
this.begin=begin; -
this.end=end; -
this.s=10; -
} -
@Override -
public synchronized void run(){ //线程同步用了synchronized否则无法保证s的正确性 -
try{ //注意：await用在synchronized可能导致死锁，如果换成CyclicBarrier类会导致死锁 -
begin.await(); //等待begin统一 -
System.out.println(s+" 次"); -
s--; -
//do something -
} -
catch(Exception e){ -
e.printStackTrace(); -
} -
finally{ -
end.countDown(); -
} -
} -
public static void main(String[] args) throws Exception { -
CountDownLatch begin = new CountDownLatch(1); -
CountDownLatch end = new CountDownLatch(10); -
cD juc=new cD(begin,end); -
for(int j=0;j<10;j++){ -
new Thread(juc).start(); //开启10个线程，10个线程分别倒数1次，并让end减一次 -
} -
//开始倒数计时，开启begin的countDown()方法 -
System.out.println("开始倒数计数!。。。10次"); -
begin.countDown(); //begin减到0，则开始10个线程里面的await()方法后面的程序 -
end.await(); //阻塞程序，知道end减为0 -
System.out.println("倒数结束。。。后面的程序开始运行"); -
//do others -
} -
}
开启10个线程，共用juc类，对它的s每个线程减1，且对end对象的count减1，当end的count变为0时，倒数结束：
2.CyclicBarrier
该类从字面理解为循环屏障，它可以协同多个线程，让多个线程在这个屏障前等到，直到所有线程都到达了这个屏障时，再一起执行后面的操作。假如每个线程各有一个await，任何一个线程运行到await方法时就阻塞，直到最后一个线程运行到await时才同时返回。和之前的CountDownLatch相比，它只有await方法，而CountDownLatch是使用countDown()方法将计数器减到0，它创建的参数就是countDown的数量；CyclicBarrier创建时的int参数是await的数量。将上面的例子改为CyclicBarrier：小心与synchronized和Lock互斥锁公用，可能会导致死锁，await()方法不会释放锁。我一开始编的就发生了死锁。
-
import java.util.concurrent.CyclicBarrier; -
public class cD implements Runnable{ -
private CyclicBarrier end; -
private int s; -
public cD(CyclicBarrier end,int i){ -
this.end=end; -
s=i; -
} -
@Override -
public void run(){ //线程同步用了synchronized否则无法保证s的正确性 -
try{ -
System.out.println(s+"队准备完毕"); -
s--; -
end.await(); -
} -
catch(Exception e){ -
e.printStackTrace(); -
} -
} -
public static void main(String[] args) throws Exception { -
CyclicBarrier end = new CyclicBarrier(11); //await为10+1=11个 -
for(int j=0;j<10;j++){ -
new Thread(new cD(end,j)).start(); //开启10个线程 -
} -
end.await(); //阻塞程序，直到10个子线程全部运行的await处 -
System.out.println("\n10队全部准备结束。。。后面的程序开始运行"); -
//do others -
} -
}
结果：
3.Semaphore
该类用于控制信号量的个数，构造时传入个数。总数就是控制并发的数量。假如是5，程序执行前用acquire()方法获得信号，则可用信号变为4，程序执行完通过release()方法归还信号量，可用信号又变为5.如果可用信号为0，acquire就会造成阻塞，等待release释放信号。acquire和release方法可以不在同一个线程使用。Semaphore实现的功能就类似厕所有5个坑，假如有10个人要上厕所，那么同时只能有多少个人去上厕所呢？同时只能有5个人能够占用，当5个人中 的任何一个人让开后，其中等待的另外5个人中又有一个人可以占用了。另外等待的5个人中可以是随机获得优先机会，也可以是按照先来后到的顺序获得机会，这取决于构造Semaphore对象时传入的参数选项。单个信号量的Semaphore对象可以实现互斥锁的功能，并且可以是由一个线程获得了“锁”，再由另一个线程释放“锁”，这可应用于死锁恢复的一些场合。
例：
-
import java.util.concurrent.Semaphore; -
public class cD implements Runnable{ -
private Semaphore sema; -
private int s; -
public cD(Semaphore sema,int i){ -
this.sema=sema; -
s=i; -
} -
@Override -
public void run(){ //线程同步用了synchronized否则无法保证s的正确性 -
try{ -
sema.acquire(); //获取一个控制信号 -
System.out.println(s+"队准备完毕"); -
s--; -
} -
catch(Exception e){ -
e.printStackTrace(); -
} -
finally{ -
sema.release(); //释放信号 -
} -
} -
public static void main(String[] args) throws Exception { -
Semaphore sema = new Semaphore(2); -
for(int j=0;j<4;j++){ -
new Thread(new cD(sema,j)).start(); //开启5个线程，5个线程分别获得一个信号量，然后释放 -
} -
} -
}
结果：
4.Exchanger
这个类用于交换数据，只能用于两个线程。当一个线程运行到exchange()方法时会阻塞，另一个线程运行到exchange()时，二者交换数据，然后执行后面的程序。
-
import java.util.concurrent.Exchanger; -
public class JUCTest implements Runnable{ -
private Exchanger<String> exchange ; -
private String name; -
private String str; -
public JUCTest(Exchanger<String> exchange,String name,String str){ -
this.exchange=exchange; -
this.name=name; -
this.str=str; -
} -
@Override -
public void run(){ //线程同步用了synchronized否则无法保证s的正确性 -
try{ -
System.out.println(name+"线程自己的数据时："+str); -
String s=exchange.exchange(str); //交换数据 -
System.out.println(name+"获取另一个线程的数据："+s); -
} -
catch(Exception e){ -
e.printStackTrace(); -
} -
} -
public static void main(String[] args) throws Exception { -
Exchanger<String> ex=new Exchanger<String>(); -
new Thread(new JUCTest(ex,"zhou","Hello")).start(); -
new Thread(new JUCTest(ex,"yu","World")).start(); -
} -
}
结果：
5.Future
Future是一个接口。Future模式可以这样来描述：我有一个任务，提交给了Future，Future替我完成这个任务。期间我自己可以去做任何想做的事情。一段时间之后，我就便可以从Future那儿取出结果。就相当于下了一张订货单，一段时间后可以拿着提订单来提货，这期间可以干别的任何事情。其中Future 接口就是订货单，真正处理订单的是Executor类，它根据Future接口的要求来生产产品。它经常配合线程池来一起工作，将任务交给线程池去处理。
FutureTask是一个实现类，它实现了Runnable接口，配合Callable接口创建线程。Callable接口的call()方法作为线程执行体，call可以有返回值，也可以抛出异常。Callable对象不能直接作为Thread的目标，但用Future可以完成。
例子：
-
public static void main(String[] args)throws Exception{ -
FutureTask<Integer> task=new FutureTask<Integer>(new Callable(){public Integer call(){ return 1+2+3+4;}}); //匿名内部类 -
new Thread(task).start(); -
System.out.println("做自己的事，计算1+2+3+4交给另一个线程完成\n"); -
System.out.println("返回获取结果 "+task.get()); -
}
结果：
做自己的事，计算1+2+3+4交给另一个线程完成9.线程状态转移模型
一，简介
线程有新建，就绪，运行，阻塞，死亡5种状态。其中线程阻塞指的是暂停一个线程继续向下执行以等待某个条件发生（如某资源就绪等）。
二，状态转移模型
通常引起一个运行线程进入阻塞状态的方法有:sleep(),join(),wait()等。
1) sleep() 方法：sleep() 允许指定以毫秒为单位的一段时间作为参数，它使得线程在指定的时间内进入阻塞状态，不能得到CPU 调度执行，指定的时间一过，线程重新进入可执行状态（就绪状态）。等待CPU的调度执行（从阻塞点继续向下执行）。
2) join()方法：可以将两个交替执行的线程合并为顺序执行。比如在线程B中调用了线程A的join()方法，直到线程A执行完毕后，才会继续执行线程B,在调用A.join()时，线程B进入阻塞状态，当线程A执行完毕以后，线程B才会从阻塞状态变为就绪状态，等待CPU的调度执行。join(time)方法：传入等待的时间参数time，在该时间time内，线程B处于阻塞状态，过了指定的时间以后，线程B变为就绪状态(不管线程A是否执行完毕)。
3) wait()方法:使当前线程暂停执行,进入阻塞状态并释放锁标志，让其他线程可以进入Synchronized数据块，当前线程被放入对象(调用wait方法的那个对象)等待池中。当调用notify()方法后，将从对象的等待池中移走一个任意的线程并放到锁标志等待池中，只有锁标志等待池中的线程能够获取锁标志；如果对象等待池中没有线程，则notify()不起作用。notifyAll()则从对象等待池中移走所有等待那个对象的线程并放到锁标志等待池中。由此可以看出：对象等待池和锁标志等待池中的线程都是处于阻塞状态的。只有当锁标志等待池中的阻塞线程得到锁以后，才会变为就绪状态，等待CPU的调度执行。
4）yield()方法只是让运行线程转为就绪状态，进入就绪线程池中，再次等待CPU的调度执行，并不是让线程进入阻塞状态。这也就是为什么yield()方法只能让相同(或者更高)优先级的线程有执行的机会（CPU线程调度方式：按优先级抢占式调度），而sleep()则可以让比其低优先级的线程有执行的机会。
三，总结
sleep(),join()和iO等待，这种状态下线程不会释放获得的锁，而wait()会释放获得的锁
10.数据库中如何存IP地址
为什么要问如何存储IP
首先就来阐明一下部分人得反问：为什么要问IP得知怎样存，直接varchar类型不久得了吗？
其实做任何程序设计都要在功能实现的基础上最大限度的优化性能。而数据库设计是程序设计中不可忽略的一个重要部分，所以巧存IP地址可以一定程度获得很大提升。
利用函数算法处理
在MySQL中没有直接提供IP类型字段，但如果有两个函数可以把IP与最大长度为10位数字类型互转，所以使用int类型存储IP比varchar类型存储IP地址性能要提升很多，减少不少看空间。因为varchar是可变长形，需要多余的一个字节存储长度。另外int型在逻辑运算上要比varchar速度快。
IP转数字函数inet_aton()
11.map、list、set的区别
作者：天禾裕
链接：https://www.nowcoder.com/discuss/76933?type=2&order=0&pos=8&page=1
来源：牛客网
List：
- 可以允许重复的对象。
- 可以插入多个null元素。
- 是一个有序容器，保持了每个元素的插入顺序，输出的顺序就是插入的顺序。
- 常用的实现类有 ArrayList、LinkedList 和 Vector。ArrayList 最为流行，它提供了使用索引的随意访问，而 LinkedList 则对于经常需要从 List中添加或删除元素的场合更为合适。
Set：
- 不允许重复对象
- 无序容器，你无法保证每个元素的存储顺序，TreeSet通过 Comparator 或者 Comparable 维护了一个排序顺序。
- 只允许一个 null 元素
- Set 接口最流行的几个实现类是 HashSet、LinkedHashSet 以及 TreeSet。最流行的是基于 HashMap 实现的 HashSet；TreeSet 还实现了 SortedSet 接口，因此 TreeSet 是一个根据其 compare() 和 compareTo() 的定义进行排序的有序容器。
Map:
- Map不是collection的子接口或者实现类。Map是一个接口。
- Map 的 每个 Entry 都持有两个对象，也就是一个键一个值，Map 可能会持有相同的值对象但键对象必须是唯一的。
- TreeMap 也通过 Comparator 或者 Comparable 维护了一个排序顺序。
- Map 里你可以拥有随意个 null 值但最多只能有一个 null 键。
- Map 接口最流行的几个实现类是 HashMap、LinkedHashMap、Hashtable 和 TreeMap。（HashMap、TreeMap最常用）
有没有有序的set？
有，LinkedHashSet和TreeSet
12.进程间通信方式优缺点
进程间通信的方式有很多，常见的有信号，信号量，消息队列，管道，共享内存，和socket等，这里我们主要讨论管道，共享内存，和socket，其他的比较简单只做简单的介绍。
信号：信号主要用于通知某个进程发生了什么事，就像你打电话通知某个人某件事一样，事先注册号信号相应的注册函数就可以了。
信号量：信号量实际上是一个计数器，通常在多线程或者多进程开发中会用到，主要用来控制多线程多进程对于共享资源访问，通常配合锁来实现同时只有一个进程或者线程操作共享资源，防止数据的不同步。
消息队列：消息队列是消息的链表，存放在内核中并由消息队列表示符，我们可以在两个进程之间通过消息队列来实现进程间通信。不过消息队列在工作中好像并不怎么常用。
接下来主要谈谈剩下的三种，这些是我们经常会用到的。
管道分为有名管道和无名管道两种
无名管道 ：主要用于父进程与子进程之间，或者两个兄弟进程之间。在linux系统中可以通过系统调用建立起一个单向的通信管道，且这种关系只能由父进程来建立。因此，每个管道都是单向的，当需要双向通信时就需要建立起两个管道。管道两端的进程均将该管道看做一个文件，一个进程负责往管道中写内容，而另一个从管道中读取。这种传输遵循“先入先出”（FIFO）的规则。
有名管道：命名管道是为了解决无名管道只能用于近亲进程之间通信的缺陷而设计的。命名管道是建立在实际的磁盘介质或文件系统（而不是只存在于内存中）上有自己名字的文件，任何进程可以在任何时间通过文件名或路径名与该文件建立联系。为了实现命名管道，引入了一种新的文件类型——FIFO文件（遵循先进先出的原则）。实现一个命名管道实际上就是实现一个FIFO文件。命名管道一旦建立，之后它的读、写以及关闭操作都与普通管道完全相同。虽然FIFO文件的inode节点在磁盘上，但是仅是一个节点而已，文件的数据还是存在于内存缓冲页面中，和普通管道相同。
管道有很多致命的缺点，比如只能在具有亲缘关系的进程间通信，只能单向传输数据，另外管道的缓冲区是有限的（管道制存在于内存中，在管道创建时，为缓冲区分配一个页面大小，管道所传送的是无格式字节流，这就要求管道的读出方和写入方必须事先约定好数据的格式，最后就是管道操作不当很容易阻塞。因此管道虽然偶尔会见到，但是很少人会用。
共享内存：这个是经常用的，共享内存号称是最快的进程间通信方式，她在系统内存中开辟一块内存区，分别映射到各个进程的虚拟地址空间中，任何一个进程操作了内存区都会反映到其他进程中，各个进程之间的通信并没有像copy数据一样从内核到用户，再从用户到内核的拷贝。这种方式可以像访问自己的私有空间一样访问共享内存区，但是这事这种特性加大了共享内存的编程难度，对于数据的同步问题是一个难点，没有一定的经验很 容易造成数据的混乱。但是我们可以使用一个折中的方法，我们可以结合它和管道来使用。
举个例子进程A和B通信，如果我们用一块共享内存区来实现它们的通信，对于数据的同步是个令人头疼的问题，但是我们可以用两个共享内存区。
内存区 1 ，A->B,A只能写数据，B只能读数据
内存区 2， B->A,A只能读数据，B只能写数据
这样就不会因为，多个进程同时鞋一块内存造成数据的混乱了，看起来是不是有点像管道，其实就是管道的机制，但是不同的是，她的速度要比管道快的多，他的数据大小没有限制（当然不能超过系统的内存大小），当然也不会有阻塞问题。但是这种方式也有明显的缺点，它只适合点对点的通信，如果要多个进程间通信，内存区的数量会呈线性增长，会造成数据的冗余，并且管理起来也会变得困难,如果你的进程数量在各位数着中方式是一个好的选择，否则就要采用一块共享内存，同时做好数据的同步了。(对于这种模式我写了一个小的domo供大家参考:博客：点击打开链接，github：点击打开链接)
最后一点，通过名字就知道它是基于内存的，所以他只能在同一主机上使用，如果我们要做分布式应用或者跨物理机通信，那么socket就是我们唯一的选择了。
socket是一种面相网络的一种进程间通信方式，只要有网络存在，它可以跨越任何限制。socket编程是一个宽泛的说法，对于我们程序猿来说tcp，udp，http是我们经常用的一些网络协议。当然socket也是我们用的最多的，他的限制住要在与带宽，网络延时和连接数量的限制等。这也是我们在开发服务程序时都要面对c10k问题的原因。
下面看一段别人对于使用这些方式的前提的看法:(来源:http://blog.csdn.net/fengye245/article/details/7783717)
1. 联网的还是非联网的.IPC适用于单台主机上的进程或线程间的.如果应用程序有可能分布到多台主机上,那就要考虑使用套接字代替IPC,从而简化以后向联网的应用程序转移的工作.
2. 可移植性.
3. 性能,在具体的开发环境下运行测试程序,比较几种IPC的性能差异.
4. 实时调度.如果需要这一特性,而且所用的系统也支持posix实时调度选项,那就考虑使用Posix的消息传递和同步函数.
13.软连接硬连接
硬链接与软链接的联系与区别
我们知道文件都有文件名与数据，这在 Linux 上被分成两个部分：用户数据 (user data) 与元数据 (metadata)。用户数据，即文件数据块 (data block)，数据块是记录文件真实内容的地方；而元数据则是文件的附加属性，如文件大小、创建时间、所有者等信息。在 Linux 中，元数据中的 inode 号（inode 是文件元数据的一部分但其并不包含文件名，inode 号即索引节点号）才是文件的唯一标识而非文件名。文件名仅是为了方便人们的记忆和使用，系统或程序通过 inode 号寻找正确的文件数据块。图 1.展示了程序通过文件名获取文件内容的过程。
图 1. 通过文件名打开文件
清单 3. 移动或重命名文件
| 1 2 3 4 5 6 7 8 9 10 |
|
在 Linux 系统中查看 inode 号可使用命令 stat 或 ls -i（若是 AIX 系统，则使用命令 istat）。清单 3.中使用命令 mv 移动并重命名文件 glibc-2.16.0.tar.xz，其结果不影响文件的用户数据及 inode 号，文件移动前后 inode 号均为：2485677。
为解决文件的共享使用，Linux 系统引入了两种链接：硬链接 (hard link) 与软链接（又称符号链接，即 soft link 或 symbolic link）。链接为 Linux 系统解决了文件的共享使用，还带来了隐藏文件路径、增加权限安全及节省存储等好处。若一个 inode 号对应多个文件名，则称这些文件为硬链接。换言之，硬链接就是同一个文件使用了多个别名（见 图 2.hard link 就是 file 的一个别名，他们有共同的 inode）。硬链接可由命令 link 或 ln 创建。如下是对文件 oldfile 创建硬链接。
| 1 2 |
|
由于硬链接是有着相同 inode 号仅文件名不同的文件，因此硬链接存在以下几点特性：
- 文件有相同的 inode 及 data block；
- 只能对已存在的文件进行创建；
- 不能交叉文件系统进行硬链接的创建；
- 不能对目录进行创建，只可对文件创建；
- 删除一个硬链接文件并不影响其他有相同 inode 号的文件。
清单 4. 硬链接特性展示
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
文件 old.file 与 hard.link 有着相同的 inode 号：660650 及文件权限，inode 是随着文件的存在而存在，因此只有当文件存在时才可创建硬链接，即当 inode 存在且链接计数器（link count）不为 0 时。inode 号仅在各文件系统下是唯一的，当 Linux 挂载多个文件系统后将出现 inode 号重复的现象（如 清单 5.所示，文件 t3.jpg、sync 及 123.txt 并无关联，却有着相同的 inode 号），因此硬链接创建时不可跨文件系统。设备文件目录 /dev 使用的文件系统是 devtmpfs，而 /root（与根目录 / 一致）使用的是磁盘文件系统 ext4。清单 5.展示了使用命令 df 查看当前系统中挂载的文件系统类型、各文件系统 inode 使用情况及文件系统挂载点。
清单 5. 查找有相同 inode 号的文件
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
值得一提的是，Linux 系统存在 inode 号被用完但磁盘空间还有剩余的情况。我们创建一个 5M 大小的 ext4 类型的 mo.img 文件，并将其挂载至目录 /mnt。然后我们使用一个 shell 脚本将挂载在 /mnt 下 ext4 文件系统的 indoe 耗尽（见清单 6.）。
清单 6. 测试文件系统 inode 耗尽但仍有磁盘空间的情景
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
硬链接不能对目录创建是受限于文件系统的设计（见 清单 4.对目录创建硬链接将失败）。现 Linux 文件系统中的目录均隐藏了两个个特殊的目录：当前目录（.）与父目录（..）。查看这两个特殊目录的 inode 号可知其实这两目录就是两个硬链接（注意目录 /mnt/lost+found/ 的 inode 号）。若系统允许对目录创建硬链接，则会产生目录环。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
软链接与硬链接不同，若文件用户数据块中存放的内容是另一文件的路径名的指向，则该文件就是软连接。软链接就是一个普通文件，只是数据块内容有点特殊。软链接有着自己的 inode 号以及用户数据块（见 图 2.）。因此软链接的创建与使用没有类似硬链接的诸多限制：
- 软链接有自己的文件属性及权限等；
- 可对不存在的文件或目录创建软链接；
- 软链接可交叉文件系统；
- 软链接可对文件或目录创建；
- 创建软链接时，链接计数 i_nlink 不会增加；
- 删除软链接并不影响被指向的文件，但若被指向的原文件被删除，则相关软连接被称为死链接（即 dangling link，若被指向路径文件被重新创建，死链接可恢复为正常的软链接）。
图 2. 软链接的访问
清单 7. 软链接特性展示
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
当然软链接的用户数据也可以是另一个软链接的路径，其解析过程是递归的。但需注意：软链接创建时原文件的路径指向使用绝对路径较好。使用相对路径创建的软链接被移动后该软链接文件将成为一个死链接（如下所示的软链接 a 使用了相对路径，因此不宜被移动），因为链接数据块中记录的亦是相对路径指向。
14.linux权限
-
[ugoa...]
-
u 表示该档案的拥有者，g 表示与该档案的拥有者属于同一个群体(group)者，o 表示其他以外的人，a 表示所有（包含上面三者）。
-
[+-=]
-
+ 表示增加权限，- 表示取消权限，= 表示唯一设定权限。
-
[rwxX]
-
r 表示可读取，w 表示可写入，x 表示可执行，X 表示只有当该档案是个子目录或者该档案已经被设定过为可执行。
- -rw------- (600) 只有拥有者有读写权限。
-rw-r--r-- (644) 只有拥有者有读写权限；而属组用户和其他用户只有读权限。
-rwx------ (700) 只有拥有者有读、写、执行权限。
-rwxr-xr-x (755) 拥有者有读、写、执行权限；而属组用户和其他用户只有读、执行权限。
-rwx--x--x (711) 拥有者有读、写、执行权限；而属组用户和其他用户只有执行权限。
-rw-rw-rw- (666) 所有用户都有文件读、写权限。
-rwxrwxrwx (777) 所有用户都有读、写、执行权限。
15.什么时候该建索引
索引可以提高数据的检索效率，也可以降低数据库的IO成本，并且索引还可以降低数据库的排序成本。排序分组操作主要消耗的就是CPU资源和内存，所以能够在排序分组操作中好好的利用索引将会极大地降低CPU资源的消耗。
如何判定是否需要创建索引？
1、较频繁地作为查询条件的字段
这个都知道。什么是教频繁呢？分析你执行的所有SQL语句。最好将他们一个个都列出来。然后分析，发现其中有些字段在大部分的SQL语句查询时候都会用到，那么就果断为他建立索引。
2、唯一性太差的字段不适合建立索引
什么是唯一性太差的字段。如状态字段、类型字段。那些只存储固定几个值的字段，例如用户登录状态、消息的status等。这个涉及到了索引扫描的特性。例如：通过索引查找键值为A和B的某些数据，通过A找到某条相符合的数据，这条数据在X页上面，然后继续扫描，又发现符合A的数据出现在了Y页上面，那么存储引擎就会丢弃X页面的数据，然后存储Y页面上的数据，一直到查找完所有对应A的数据，然后查找B字段，发现X页面上面又有对应B字段的数据，那么他就会再次扫描X页面，等于X页面就会被扫描2次甚至多次。以此类推，所以同一个数据页可能会被多次重复的读取，丢弃，在读取，这无疑给存储引擎极大地增加了IO的负担。
3、更新太频繁地字段不适合创建索引
当你为这个字段创建索引时候，当你再次更新这个字段数据时，数据库会自动更新他的索引，所以当这个字段更新太频繁地时候那么就是不断的更新索引，性能的影响可想而知。大概被检索几十次会更新一次的字段才比较符合建立索引的规范。而如果一个字段同一个时间段内被更新多次，那么果断不能为他建立索引。
4、不会出现在where条件中的字段不该建立索引
16.Mysql 中 MyISAM 和 InnoDB 的区别有哪些？
区别：
1. InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；
3. InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
4. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
5. Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；
如何选择：
1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；
2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读写也挺频繁，请使用InnoDB。
3. 系统奔溃后，MyISAM恢复起来更困难，能否接受；
4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。
17.什么是cdn
第一步，HTML的文件引用：
HTML的文件头（也有文件中，文件尾）那边常有其他文件引用，比如CSS以及JS的引用。
就以bootstrap常用的引用来举个栗子
你常见的引用可能会是这样的：
<head>
<title>Mushroom</title>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,Chrome=1" />
<meta http-equiv="X-UA-Compatible" content="IE=9" />
<!-- 引入 Bootstrap -->
<link href="/css/bootstrap.min.css" rel="stylesheet">
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="/js/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="/js/bootstrap.min.js"></script>
</head>
这之中，<script src="/js/bootstrap.min.js"></script> 这段就是外部脚本文件的一个链接，当前的这种链接是相对URL，指向站点内的文件，即你本项目里对应路径下面放置的文件。可以在 HTML <script> 标签的 src 属性 查看这个标签的具体属性。
属性值
值 描述
URL 外部脚本的 URL。可能的值有：
•绝对 URL - 指向其他站点（比如 src="www.example.com/example.js"）
•相对 URL - 指向站点内的文件（比如 src="/scripts/example.js"）
通过查看可以得知，URL的引用有两种方式，绝对和相对，绝对的方式就是直接引用其他站点的js地址，比如我把上方的引用改为
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>
这样即是引用其他站点的js。
CSS文件的引用与此类似：HTML <link> 标签的 href 属性
图片以及其他文件的引用也类似，不赘述。
第二步，系统的资源引用
在一个网站项目中，页面里经常会有许多js以及css的引用，接触过开发项目的一般都会了解，大部分界面里的脚本引用并不是像第一步里的那么精简，如果是直接引用项目内文件的话，他们可能是这样的：
<SCRIPT src="/iforums/templates/default/js/common.js" type=text/javascript></SCRIPT>
<SCRIPT src="/iforums/templates/default/js/ajax.js" type=text/javascript></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/third-party/jquery-1.10.2.min.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.config.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.parse.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.all.js"></SCRIPT>
可能甚至引用的更多，这样将资源文件与业务代码一锅炖的方式适用于小型的，应用服务器压力并不是太大的系统（并发、带宽、存储空间、资源等等）。这种方式的优点是开发省力，发布省力，对服务器要求小，省钱，没有具体公网接入需求。许多小型，内部使用型的网站系统往往采取这种形式放置资源文件。
第三步，系统访问量变高了，速度变慢了怎么办
怎么办？优化系统部署呗。
怎么优化？优化方式有很多，读写分离，负载均衡，这方面的东西可以讲上三天三夜。具体到本问题的范畴内，那就是资源服务器与应用服务器的分离。粗暴的理解方式就是，就是应用安在应用服务器（一台或者是集群），资源部署在资源服务器（单台或者是集群），这时候，js以及css的引用就需要更改为绝对URL，指向对应的资源服务器。
比如知乎的引用：
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(57px).png" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(72px).png" sizes="72x72" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(76px).png" sizes="76x76" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(114px).png" sizes="114x114" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(120px).png" sizes="120x120" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(152px).png" sizes="152x152" />
<script src="http://static.zhihu.com/static/revved/js/-/vendor.min.5a2082ff.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app_core.fb4023ac.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/sign.e0ca7b10.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app.9eaaec15.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/rich_text_editor.3a07c473.js"></script>
有兴趣的话，你可以打开这个链接看看是什么页面：http://static.zhihu.com/
也可以打开这个看看：http://static.zhihu.com/static
第四步，网络方面的优化
网站的访问速度，只基于一点，那就是页面包含的内容传输到用户电脑的速度，服务器搭的再好再完美，如果用户到服务器的链路之间有一段比较缓慢的话，整体速度也会被拉的十分差劲。
想象一下，你给公司做了个运行于公司内网的网站，一切运行良好，分布式部署也已搭建完毕，一切都很完美。
后来，你公司运营良好，开了一个十分遥远的分公司（不要问为什么遥远，再问自绝经脉），你们的内网也同时连了过去（对，就是那种很直接的搭了几条网线就把两个局域网连成一个局域网的黑科技）。但是因为太远了线节点太多了，分公司访问公司的系统十分缓慢，这时候你就愁啊，这可咋办？那不行就在分公司那边部署一套内容缓存好了，内容进行同步，这样至少分公司的网页访问速度能提升很多，你也可以立功升职加薪了。
紧接着，因为你的出色表现，你们公司扩展十分厉害，在全国各地都建立了分公司，你又开始愁了，这不能每个分公司都搭一套啊，累得慌啊。思来想去，那就华东一套华北一套华南一套东北一套这样分吧，然后搭一些分发服务器，接入访问地址，然后跳转到就近的内容缓存服务器进行内容读取，OK，又到了升职加薪的时刻了~
对，到这里，你已经完成了一套简易CDN的建设。
第五步，CDN是什么？
你的搭建只是基于你公司的大型局域网，而现行的流行CDN则是基于地球搭建的超大型局域网--因特网。它的好处是什么呢？
比如你这么写：
<!-- 引入 Bootstrap -->
<link href="http://apps.bdimg.com/libs/bootstrap/3.3.0/css/bootstrap.min.css" rel="stylesheet">
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="http://apps.bdimg.com/libs/html5shiv/3.7/html5shiv.min.js"></script>
<script src="http://apps.bdimg.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="http://apps.bdimg.com/libs/jquery/2.1.4/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>
上面的地址是百度CDN的链接地址。
那么用户在读取网页内容的时候，就会去百度的就近服务器上掏这些js和css，而不是在你的服务器里捞。
好处呢，第一，一般来说，访问速度有保障，稳定性也有保障；第二，你可以省下资源服务器的一部分资源负担，节省空间节省流量，艰苦创业，能省则省啊。
这时候你会问了，为什么只有js和css呢？其他的图片啊html内容啊不能放进CDN吗？
能啊为啥不能，CDN服务就靠这赚钱呢为啥不能，非广告非广告非广告，你看：
CDN-Content Delivery Network-百度开放云
同类产品还有阿里云等等等等。。
你看的文章中的CDN，一般都是指js和css文件的CDN存储，而对于你的两个问题，遗憾的告诉你，不是，不能。
18.Redis中5种数据结构的使用场景介绍
一、redis 数据结构使用场景
原来看过 redisbook 这本书，对 redis 的基本功能都已经熟悉了，从上周开始看 redis 的源码。目前目标是吃透 redis 的数据结构。我们都知道，在 redis 中一共有5种数据结构，那每种数据结构的使用场景都是什么呢？
String——字符串
Hash——字典
List——列表
Set——集合
Sorted Set——有序集合
下面我们就来简单说明一下它们各自的使用场景：
-
String——字符串
String 数据结构是简单的 key-value 类型，value 不仅可以是 String，也可以是数字（当数字类型用 Long 可以表示的时候encoding 就是整型，其他都存储在 sdshdr 当做字符串）。使用 Strings 类型，可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作：
1.LEN niushuai：O(1)获取字符串长度
2.APPEND niushuai redis：往字符串 append 内容，而且采用智能分配内存（每次2倍）
3.设置和获取字符串的某一段内容
4.设置及获取字符串的某一位（bit）
5.批量设置一系列字符串的内容
6.原子计数器
7.GETSET 命令的妙用，请于清空旧值的同时设置一个新值，配合原子计数器使用
-
Hash——字典
在 Memcached 中，我们经常将一些结构化的信息打包成 hashmap，在客户端序列化后存储为一个字符串的值（一般是 JSON 格式），比如用户的昵称、年龄、性别、积分等。这时候在需要修改其中某一项时，通常需要将字符串（JSON）取出来，然后进行反序列化，修改某一项的值，再序列化成字符串（JSON）存储回去。简单修改一个属性就干这么多事情，消耗必定是很大的，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而 Redis 的 Hash 结构可以使你像在数据库中 Update 一个属性一样只修改某一项属性值。
存储、读取、修改用户属性
-
List——列表
List 说白了就是链表（redis 使用双端链表实现的 List），相信学过数据结构知识的人都应该能理解其结构。使用 List 结构，我们可以轻松地实现最新消息排行等功能（比如新浪微博的 TimeLine ）。List 的另一个应用就是消息队列，可以利用 List 的 *PUSH 操作，将任务存在 List 中，然后工作线程再用 POP 操作将任务取出进行执行。Redis 还提供了操作 List 中某一段元素的 API，你可以直接查询，删除 List 中某一段的元素
1.微博 TimeLine
2.消息队列
-
Set——集合
Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
1.共同好友、二度好友
2.利用唯一性，可以统计访问网站的所有独立 IP
3.好友推荐的时候，根据 tag 求交集，大于某个 threshold 就可以推荐
-
Sorted Set——有序集合
和Sets相比，Sorted Sets是将 Set 中的元素增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用 Sorted Sets 来做带权重的队列，比如普通消息的 score 为1，重要消息的 score 为2，然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行。
1.带有权重的元素，比如一个游戏的用户得分排行榜
2.比较复杂的数据结构，一般用到的场景不算太多
二、redis 其他功能使用场景
-
订阅-发布系统
Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在 Redis 中，你可以设定对某一个 key 值进行消息发布及消息订阅，当一个 key 值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。
-
事务——Transactions
谁说 NoSQL 都不支持事务，虽然 Redis 的 Transactions 提供的并不是严格的 ACID 的事务（比如一串用 EXEC 提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个 Transactions 还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis 还提供了一个 Watch 功能，你可以对一个 key 进行 Watch，然后再执行 Transactions，在这过程中，如果这个 Watched 的值进行了修改，那么这个 Transactions 会发现并拒绝执行。
19.Redis是基于内存的么——是，所以高性能
20.跳跃表
跳跃表（skiplist）是一种随机化的数据， 由 William Pugh 在论文《Skip lists: a probabilistic alternative to balanced trees》中提出， 跳跃表以有序的方式在层次化的链表中保存元素， 效率和平衡树媲美 —— 查找、删除、添加等操作都可以在对数期望时间下完成， 并且比起平衡树来说， 跳跃表的实现要简单直观得多。
以下是个典型的跳跃表例子（图片来自维基百科）：
从图中可以看到， 跳跃表主要由以下部分构成：
- 表头（head）：负责维护跳跃表的节点指针。
- 跳跃表节点：保存着元素值，以及多个层。
- 层：保存着指向其他元素的指针。高层的指针越过的元素数量大于等于低层的指针，为了提高查找的效率，程序总是从高层先开始访问，然后随着元素值范围的缩小，慢慢降低层次。
- 表尾：全部由
NULL组成，表示跳跃表的末尾。
因为跳跃表的定义可以在任何一本算法或数据结构的书中找到， 所以本章不介绍跳跃表的具体实现方式或者具体的算法， 而只介绍跳跃表在 Redis 的应用、核心数据结构和 API 。
跳跃表的实现
为了满足自身的功能需要， Redis 基于 William Pugh 论文中描述的跳跃表进行了以下修改：
- 允许重复的
score值：多个不同的member的score值可以相同。 - 进行对比操作时，不仅要检查
score值，还要检查member：当score值可以重复时，单靠score值无法判断一个元素的身份，所以需要连member域都一并检查才行。 - 每个节点都带有一个高度为 1 层的后退指针，用于从表尾方向向表头方向迭代：当执行 ZREVRANGE 或 ZREVRANGEBYSCORE 这类以逆序处理有序集的命令时，就会用到这个属性。
这个修改版的跳跃表由 redis.h/zskiplist 结构定义：
typedef struct zskiplist {
// 头节点，尾节点
struct zskiplistNode *header, *tail;
// 节点数量
unsigned long length;
// 目前表内节点的最大层数
int level;
} zskiplist;
跳跃表的节点由 redis.h/zskiplistNode 定义：
typedef struct zskiplistNode {
// member 对象
robj *obj;
// 分值
double score;
// 后退指针
struct zskiplistNode *backward;
// 层
struct zskiplistLevel {
// 前进指针
struct zskiplistNode *forward;
// 这个层跨越的节点数量
unsigned int span;
} level[];
} zskiplistNode;
以下是操作这两个数据结构的 API ，API 的用途与相应的算法复杂度：
| 函数 | 作用 | 复杂度 |
|---|---|---|
zslCreateNode |
创建并返回一个新的跳跃表节点 | 最坏 O(1)O(1) |
zslFreeNode |
释放给定的跳跃表节点 | 最坏 O(1)O(1) |
zslCreate |
创建并初始化一个新的跳跃表 | 最坏 O(1)O(1) |
zslFree |
释放给定的跳跃表 | 最坏 O(N)O(N) |
zslInsert |
将一个包含给定 score 和 member 的新节点添加到跳跃表中 |
最坏 O(N)O(N) 平均 O(logN)O(logN) |
zslDeleteNode |
删除给定的跳跃表节点 | 最坏 O(N)O(N) |
zslDelete |
删除匹配给定 member 和 score 的元素 |
最坏 O(N)O(N) 平均 O(logN)O(logN) |
zslFirstInRange |
找到跳跃表中第一个符合给定范围的元素 | 最坏 O(N)O(N) 平均 O(logN)O(logN) |
zslLastInRange |
找到跳跃表中最后一个符合给定范围的元素 | 最坏 O(N)O(N) 平均 O(logN)O(logN) |
zslDeleteRangeByScore |
删除 score 值在给定范围内的所有节点 |
最坏 O(N2)O(N2) |
zslDeleteRangeByRank |
删除给定排序范围内的所有节点 | 最坏 O(N2)O(N2) |
zslGetRank |
返回目标元素在有序集中的排位 | 最坏 O(N)O(N) 平均 O(logN)O(logN) |
zslGetElementByRank |
根据给定排位，返回该排位上的元素节点 | 最坏 O(N)O(N) 平均 O(logN)O(logN) |
跳跃表的应用
和字典、链表或者字符串这几种在 Redis 中大量使用的数据结构不同， 跳跃表在 Redis 的唯一作用， 就是实现有序集数据类型。
跳跃表将指向有序集的 score 值和 member 域的指针作为元素， 并以 score 值为索引， 对有序集元素进行排序。
举个例子， 以下代码创建了一个带有 3 个元素的有序集：
redis> ZADD s 6 x 10 y 15 z
(integer) 3
redis> ZRANGE s 0 -1 WITHSCORES
1) "x"
2) "6"
3) "y"
4) "10"
5) "z"
6) "15"
在底层实现中， Redis 为 x 、 y 和 z 三个 member 分别创建了三个字符串， 值分别为 double 类型的 6 、 10 和 15 ， 然后用跳跃表将这些指针有序地保存起来， 形成这样一个跳跃表：
![digraph zset { rankdir = LR; node [shape = record, style = filled]; edge [style = bold]; skiplist [label ="<head>zskipNode\n(head) |<3> |<2> |<1> |<score>score\n NULL |<robj>robj\n NULL", fillcolor = "#F2F2F2"]; six [label = "<head>zskipNode |<3> |<2> |<1> |<score>score\n 6 |<robj>robj\n x", fillcolor = "#95BBE3"]; ten [label = "<head>zskipNode | <1> |<score>score\n 10 |<robj>robj\n y", fillcolor = "#95BBE3"]; fiften [label = "<head>zskipNode |<3> |<2> |<1> |<score>score\n 15 |<robj>robj\n z", fillcolor = "#95BBE3"]; skiplist:3 -> six:3; skiplist:2 -> six:2; skiplist:1 -> six:1; six:1 -> ten:1; six:2 -> fiften:2; six:3 -> fiften:3; ten:1 -> fiften:1; null_1 [label = "NULL", shape=plaintext]; null_2 [label = "NULL", shape=plaintext]; null_3 [label = "NULL", shape=plaintext]; fiften:1 -> null_1; fiften:2 -> null_2; fiften:3 -> null_3; }](https://redisbook.readthedocs.io/en/latest/_images/graphviz-ba063df77d0d9a6581ef14368644db453ab8a7f7.svg)
为了方便展示， 在图片中我们直接将 member 和 score 值包含在表节点中， 但是在实际的定义中， 因为跳跃表要和另一个实现有序集的结构（字典）分享 member 和 score 值， 所以跳跃表只保存指向 member 和 score 的指针。 更详细的信息，请参考《有序集》章节。
小结
- 跳跃表是一种随机化数据结构，查找、添加、删除操作都可以在对数期望时间下完成。
- 跳跃表目前在 Redis 的唯一作用，就是作为有序集类型的底层数据结构（之一，另一个构成有序集的结构是字典）。
- 为了满足自身的需求，Redis 基于 William Pugh 论文中描述的跳跃表进行了修改，包括：
score值可重复。- 对比一个元素需要同时检查它的
score和memeber。 - 每个节点带有高度为 1 层的后退指针，用于从表尾方向向表头方向迭代。
21.Top K问题
在处理大量数据的时候，有时候往往需要找出Top前几的数据，这时候如果直接对数据进行排序，在处理海量数据的时候往往就是不可行的了，而且在排序最好的时间复杂度为nlogn，当n远大于需要获取到的数据的时候，时间复杂度就显得过高。
使用最小堆或者最大堆可以很好地解决Top大问题或者Top小问题。
- Top大问题解决思路：使用一个固定大小的最小堆，当堆满后，每次添加数据的时候与堆顶元素比较，若小于堆顶元素，则舍弃，若大于堆顶元素，则删除堆顶元素，添加新增元素，对堆进行重新排序。
- Top小问题解决思路：使用一个固定大小的最大堆，当堆满后，每次添加数据到时候与堆顶元素进行比较，若大于堆顶元素，则舍弃，若小于堆顶元素，则删除堆顶元素，添加新增元素，对堆进行重新排序。
对于n个数，取Top m个数，时间复杂度为O(nlogm)，这样在n较大情况下，是优于nlogn的时间复杂度的。
比如10000个数据，取前100大的数，那么时间复杂度就是O(10000log100)。
因为在插入数据的时候需要遍历元素时间复杂度达到了O(10000)，然后每次插入过程中进行调整的复杂度为O(log100)，所以总体时间复杂度为O(10000log100)。
使用Java类库集合实现
Java集合中的PriorityQueue就可以实现最大堆或者最小堆，从名字可以知道该集合是优先队列，数据结构中的优先队列就是使用堆来实现的。
// 底层通过一个Object类型数据保存元素
transient Object[] queue;
// 通过Comparator制定比较方法
private final Comparator<? super E> comparator;
// 其中一个构造函数
public PriorityQueue(int initialCapacity,
Comparator<? super E> comparator) {
// Note: This restriction of at least one is not actually needed,
// but continues for 1.5 compatibility
if (initialCapacity < 1)
throw new IllegalArgumentException();
this.queue = new Object[initialCapacity];
this.comparator = comparator;
}下面就使用PriorityQueue来实现最小堆和最大堆。
- 在构造PriorityQueue的时候需要传入一个size和一个比较函数，制定堆中元素比较规则。
- 重写compare(o1, o2)方法，最小堆使用o1 - o2，最大堆使用o2 - o1。
public class TopK<E extends Comparable> {
private PriorityQueue<E> queue;
private int maxSize; //堆的最大容量
public TopK(int maxSize) {
if (maxSize <= 0) {
throw new IllegalStateException();
}
this.maxSize = maxSize;
this.queue = new PriorityQueue<>(maxSize, new Comparator<E>() {
@Override
public int compare(E o1, E o2) {
// 最大堆用o2 - o1，最小堆用o1 - o2
return (o1.compareTo(o2));
}
});
}
public void add(E e) {
if (queue.size() < maxSize) {
queue.add(e);
} else {
E peek = queue.peek();
if (e.compareTo(peek) > 0) {
queue.poll();
queue.add(e);
}
}
}
public List<E> sortedList() {
List<E> list = new ArrayList<>(queue);
Collections.sort(list);
return list;
}
public static void main(String[] args) {
int[] array = {4, 5, 1, 6, 2, 7, 3, 8};
TopK pq = new TopK(4);
for (int n : array) {
pq.add(n);
}
System.out.println(pq.sortedList());
}
}运行结果：
使用Java实现
通过上述讲述，基本了解最大堆和最小堆情况以及它们与TopK问题的关系，上面是使用集合实现，下面使用Java来实现最小堆，并解决TopK大问题。
- 限定数据大小。
- 若堆满，则插入过程中与堆顶元素比较，并做相应操作。
- 每次删除堆顶元素后堆做一次调整，保证最小堆特性。
public class TopK {
int[] items;
int currentSize = 0;
// 初始化为size + 1，从下标1开始保存元素。
public TopK(int size) {
items = new int[size + 1];
}
// 插入元素
public void insert(int x) {
if (currentSize == items.length - 1) {
if (compare(x, items[1]) < 0) {
return;
} else if (compare(x, items[1]) > 0) {
deleteMin();
}
}
int hole = ++currentSize;
for (items[0] = x; compare(x, items[hole / 2]) < 0; hole /= 2) {
items[hole] = items[hole / 2];
}
items[hole] = x;
}
// 删除最小堆中最小元素
public int deleteMin() {
int min = items[1];
items[1] = items[currentSize--];
percolateDown(1);
return min;
}
// 下滤
public void percolateDown(int hole) {
int child;
int temp = items[1];
for (; hole * 2 <= currentSize; hole = child) {
child = 2 * hole;
if (child != currentSize && compare(items[child + 1], items[child]) == -1) {
child++;
}
if (compare(items[child], temp) < 0) {
items[hole] = items[child];
} else {
break;
}
}
items[hole] = temp;
}
// 制定比较规则
public static int compare(int a, int b) {
if (a < b) {
return -1;
} else if (a > b) {
return 1;
}
return 0;
}
public static void main(String[] args) {
TopK topK = new TopK(10);
for (int i = 1; i <= 100; i++) {
topK.insert(i);
}
for (int j = 1; j <= topK.currentSize; j++) {
System.out.print(topK.items[j] + " ");
}
System.out.println();
}
}22.static方法
我们都知道，静态static方法中不能调用非静态(non-static)方法，准确地说是不能直接调用non-static方法。但是可以通过将一个对象的引用传入static方法中，再去调用该对象的non-static方法。
其实这个事实的应用很经常，以至于我们不去重视：在主函数(static方法)中我们经常创建某个类的实例，再利用其引用变量调用它的非静态方法。
-
class Test2{ -
public void method2(){ -
System.out.println("HelloWorld2"); -
} -
} -
class test{ -
public void method0(){ -
System.out.println("HelloWorld0"); -
} -
public static void method1(){ -
System.out.println("HelloWorld1"); -
} -
public static void main(String args[]){ -
new test().method0(); -
method1(); -
new Test2().method2(); -
} -
}
打印结果:
HelloWorld0
HelloWorld1
HelloWorld2
总结:
首先static的成员是在类加载的时候初始化的，JVM的CLASSLOADER的加载，首次主动使用加载，而非static的成员是在创建对象的时候，即new 操作的时候才初始化的；
先后顺序是先加载，才能初始化，那么加载的时候初始化static的成员，此时非static的成员还没有被加载必然不能使用，而非static的成员是在类加载之后，通过new操作符创建对象的时候初始化，此时static 已经分配内存空间，所以可以访问！
简单点说：静态成员属于类,不需要生成对象就存在了.而非静态需要生成对象才产生.所以静态成员不能直接访问非静态.
下面说说静态的特点：
1.随着类的加载而加载
也就是，说静态会随着类的消失而消失，说明静态的生命周期最长
2.优先于对象的存在
明确一点：静态是先存在的对象是后存在的
3.被所有对象共享
4.可以直接被类名多调用
实例变量和类变量的区别
1.存放位置
类变量随着类的加载存在于方法区中，实例变量随着对象的对象的建立存在于堆内存里
2.生命周期
类变量生命周期最长，随着“类”的加载而加载，随着类的消失而消失,实例变量随着“对象”的消失而消失
静态的使用注意事项：
1.静态方法只能访问静态成员（包括成员变量和成员方法）
非静态方法可以访问静态也可以访问非静态
2.静态方法中不可以定义this，super关键字
因为静态优先于对象存在，所以静态方法中不可以出现this，super关键字
3.主函数是静态的。
静态的利弊
利：对对象的共享数据进行单独空间的存储，节省空间，没有必要每一个对象中都存储一份
可以直接被类名所调用
弊：生命周期过长，访问出现局限性（只能访问静态）
23.组合和继承
组合和继承是面向对象中两种代码复用的方式。组合是指在新的类中创建原有类的对象，重复利用已有类的功能。继承是面向对象的主要特征之一，它允许设计人员根据其他类的实现来定义一个类的实现。组合和继承都允许在新的类中设置子对象，只是组合是显式的，而继承则是隐式的。组合和继承存在着对应关系：组合中的整体类和继承中的子类对应，组合中的局部类和继承中的父类对应。
二者的区别在哪里呢？首先分析一个实例。Car表示汽车对象，Vehicle表示交通工具对象，Tire表示轮胎对象。三者的关系如图所示。
从图中可以看出，Car是Vehicle的一种，因此是一种继承关系（又被称为“is - a”关系）；而Car包含了多个Tire，因此是一种组合关系（又被称为“has - a”关系）。其实现方式如下：
继承的实现方式：
Java代码
- class Verhicle{
- }
- class Car extends Verhicle{
- }
组合的实现方式：
Java代码
- class Tire{
- }
- class Car extends Verhicle{
- private Tire t = new Tire();
- }
既然继承和组合都能实现代码的重用，那么在实际使用时又该如何选择呢？一般情况下，遵循以下两点原则：
1. 除非两个类是“is - a”关系，否则不要轻易的使用继承，不要单纯的为了实现代码的重用而使用继承，因为过多的使用继承会破坏代码的可维护性。当父类被修改时，会影响到所有继承自它的子类，从而增加程序的维护难度和成本。
2. 不要仅仅为了实现多态而使用继承。如果类之间没有“is - a”关系，可以通过实现组合的方式来达到相同的目的。设计模式中的策略模式可以很好的说明这一点，采用接口和组合的方式比采用继承的方式具有更好的可扩展性。
由于Java语言只支持单继承，如果想同时继承多个类，在Java中是无法直接实现的。同时，在Java语言中，如果使用继承过多，也会让一个class里的内容臃肿不堪。所以，在Java语言中，能使用组合就尽量不要使用继承。
24.Java 面向对象编程有三大特性：封装、继承、多态
多态的好处：
a) 应用程序不必为每一个派生类编写功能调用，只需要对抽象基类进行处理即可。大大提高程序的可复用性。//继承
b) 派生类的功能可以被基类的方法或引用变量所调用，这叫向后兼容，可以提高可扩充性和可维护性。 //多态的真正作用，
25.向上转型和向下转型
转型问题其实并不复杂，只要记住一句话：父类引用指向子类对象。
什么叫父类引用指向子类对象，且听我慢慢道来.从2个名词开始说起：向上转型(upcasting) 、向下转型(downcasting).
举个例子：有2个类，Father是父类，Son类继承自Father。
Father f1 = new Son(); // 这就叫 upcasting （向上转型)
// 现在f1引用指向一个Son对象
Son s1 = (Son)f1; // 这就叫 downcasting (向下转型)
// 现在f1还是指向Son对象
第2个例子：
Father f2 = new Father();
Son s2 = (Son)f2; // 出错，子类引用不能指向父类对象
你或许会问，第1个例子中：Son s1 = (Son)f1;问什么 是正确的呢。
很简单因为f1指向一个子类对象，Father f1 = new Son(); 子类s1引用当然可以指向子类对象了。
而f2 被传给了一个Father对象，Father f2 = new Father（）；子类s1引用不能指向父类对象。
实例
- 向上转型：子类引用的对象转换为父类类型称为向上转型。通俗地说就是是将子类对象转为父类对象。此处父类对象可以是接口
- 向上转型时，父类指向子类引用对象会遗失除与父类对象共有的其他方法，也就是在转型过程中，子类的新有的方法都会遗失掉，在编译时，系统会提供找不到方法的错误
向下转型：父类引用的对象转换为子类类型称为向下转型。
父类
package testP.test;
class Person {
public void eat(){
System.out.println("Person eatting...");
}
public void sleep() {
System.out.println("Person sleep...");
}
}
向上转型
package testP.test;
public class son extends Person {
public void eat() {
System.out.println("son eatting...");
}
public void fly() {
System.out.println("son fly...");
}
public static void main(String[] args) {
Person person = new son();
person.eat(); // 调用的是son里面的eat方法，son重写了Person父类的方法
person.sleep(); //调用的是父类person的方法
person.fly(); //报错了，丢失了son类的fly方法
}
}
向下转型
在向下转型过程中，分为两种情况：
情况一：如果父类引用的对象如果引用的是指向的子类对象，那么在向下转型的过程中是安全的。也就是编译是不会出错误的。
情况二：如果父类引用的对象是父类本身，那么在向下转型的过程中是不安全的，编译不会出错，但是运行时会出现java.lang.ClassCastException错误。它可以使用instanceof来避免出错此类错误
- 安全不报错
package testP.test;
public class son extends Person {
public void eat() {
System.out.println("son eatting...");
}
public void fly() {
System.out.println("son fly...");
}
public static void main(String[] args) {
Person person = new son(); // 向上转型
son s = (son)person; //向下转型,编译和运行皆不会出错
s.fly();
s.eat();
s.sleep();
}
}
- 编译器报错
package testP.test;
public class son extends Person {
public void eat() {
System.out.println("son eatting...");
}
public void fly() {
System.out.println("son fly...");
}
public static void main(String[] args) {
Person upPerson = new Person();
son so = (son)upPerson; // 向下转型 编译器报错了
so.fly();
}
}26.int和integer
1 int与Integer的基本使用对比
（1）Integer是int的包装类；int是基本数据类型；
（2）Integer变量必须实例化后才能使用；int变量不需要；
（3）Integer实际是对象的引用，指向此new的Integer对象；int是直接存储数据值 ；
（4）Integer的默认值是null；int的默认值是0。
2 int与Integer的深入对比
（1）由于Integer变量实际上是对一个Integer对象的引用，所以两个通过new生成的Integer变量永远是不相等的（因为new生成的是两个对象，其内存地址不同）。
Integer i = new Integer(100);
Integer j = new Integer(100);
System.out.print(i == j); //false- 1
- 2
- 3
（2）Integer变量和int变量比较时，只要两个变量的值是向等的，则结果为true（因为包装类Integer和基本数据类型int比较时，java会自动拆包装为int，然后进行比较，实际上就变为两个int变量的比较）
Integer i = new Integer(100);
int j = 100；
System.out.print(i == j); //true- 1
- 2
- 3
（3）非new生成的Integer变量和new Integer()生成的变量比较时，结果为false。（因为非new生成的Integer变量指向的是java常量池中的对象，而new Integer()生成的变量指向堆中新建的对象，两者在内存中的地址不同）
Integer i = new Integer(100);
Integer j = 100;
System.out.print(i == j); //false- 1
- 2
- 3
（4）对于两个非new生成的Integer对象，进行比较时，如果两个变量的值在区间-128到127之间，则比较结果为true，如果两个变量的值不在此区间，则比较结果为false
Integer i = 100;
Integer j = 100;
System.out.print(i == j); //true
Integer i = 128;
Integer j = 128;
System.out.print(i == j); //false- 1
- 2
- 3
- 4
- 5
- 6
- 7
对于第4条的原因： java在编译Integer i = 100 ;时，会翻译成为Integer i = Integer.valueOf(100)。而java API中对Integer类型的valueOf的定义如下，对于-128到127之间的数，会进行缓存，Integer i = 127时，会将127进行缓存，下次再写Integer j = 127时，就会直接从缓存中取，就不会new了。
public static Integer valueOf(int i){
assert IntegerCache.high >= 127;
if (i >= IntegerCache.low && i <= IntegerCache.high){
return IntegerCache.cache[i + (-IntegerCache.low)];
}
return new Integer(i);
}- 1
- 2
- 3
- 4
- 5
- 6
- 7
3 Java两种数据类型
3.1 Java两种数据类型分类
（1）基本数据类型，分为boolean、byte、int、char、long、short、double、float；
（2）引用数据类型 ，分为数组、类、接口。
3.2 Java为每个原始类型提供了封装类
为了编程的方便还是引入了基本数据类型，但是为了能够将这些基本数据类型当成对象操作，Java为每 一个基本数据类型都引入了对应的包装类型（wrapper class），int的包装类就是Integer，从Java 5开始引入了自动装箱/拆箱机制，使得二者可以相互转换。
基本数据类型: boolean，char，byte，short，int，long，float，double
封装类类型：Boolean，Character，Byte，Short，Integer，Long，Float，Double- 1
- 2
4 基本解析
4.1 自动装箱：将基本数据类型重新转化为对象
public class Test {
public static void main(String[] args) {
//声明一个Integer对象
Integer num = 9;
//以上的声明就是用到了自动的装箱：解析为:Integer num = new Integer(9);
}
} - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
9是属于基本数据类型的，原则上它是不能直接赋值给一个对象Integer的，但jdk1.5后你就可以进行这样的声明。自动将基本数据类型转化为对应的封装类型，成为一个对象以后就可以调用对象所声明的所有的方法。
4.2 自动拆箱：将对象重新转化为基本数据类型
public class Test {
public static void main(String[] args) {
//声明一个Integer对象
Integer num = 9;
//进行计算时隐含的有自动拆箱
System.out.print(num--);
}
} - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
因为对象时不能直接进行运算的，而是要转化为基本数据类型后才能进行加减乘除。对比：
/装箱
Integer num = 10;
//拆箱
int num1 = num;- 1
- 2
- 3
- 4
5 深入解析
5.1 情况描述
public class Test {
public static void main(String[] args) {
//在-128~127 之外的数
Integer num1 = 128; Integer num2 = 128;
System.out.println(num1==num2); //false
// 在-128~127 之内的数
Integer num3 = 9; Integer num4 = 9;
System.out.println(num3==num4); //true
}
} - 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
解析原因：归结于java对于Integer与int的自动装箱与拆箱的设计，是一种模式：叫享元模式（flyweight）。
加大对简单数字的重利用，Java定义在自动装箱时对于值从–128到127之间的值，它们被装箱为Integer对象后，会存在内存中被重用，始终只存在一个对象。
而如果超过了从–128到127之间的值，被装箱后的Integer对象并不会被重用，即相当于每次装箱时都新建一个 Integer对象。
5.2 Integer源码解析
给一个Integer对象赋一个int值的时候，会调用Integer类的静态方法valueOf，源码如下：
public static Integer valueOf(String s, int radix) throws NumberFormatException {
return Integer.valueOf(parseInt(s,radix));
}- 1
- 2
- 3
public static Integer valueOf(int i) {
assert IntegerCache.high >= 127;
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}- 1
- 2
- 3
- 4
- 5
- 6
IntegerCache是Integer的内部类，源码如下：
/**
* 缓存支持自动装箱的对象标识语义
* -128和127（含）。
*
* 缓存在第一次使用时初始化。 缓存的大小
* 可以由-XX：AutoBoxCacheMax = <size>选项控制。
* 在VM初始化期间，java.lang.Integer.IntegerCache.high属性
* 可以设置并保存在私有系统属性中
*/
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
}
private IntegerCache() {}
}27.重写equal()时为什么也得重写hashCode()之深度解读equal方法与hashCode方法渊源
https://blog.csdn.net/javazejian/article/details/51348320
28.hashmap链地址法
上文介绍了开放地址法实现HashTable，它的缺点是对hashCode映射为地址后如果出现重复地址，则会占用其他元素的位置。这样HashTable存储容量有限，而且不便于算法理解。本文介绍链地址法实现HashMap。
链地址法内部仍然有一个数组，但区别与开放地址法，该数组存储的是一个链表的引用。当根据hashCode计算出数组下表后，对元素的增删查改都是在该数组元素所指向的链表上完成的。这就解决了hashCode重复的问题。因为，当hashCode重复，多个元素对应同一个地址，但元素实际存储的位置在数组对应的链表上。所以相同hashCode的不同元素可以存储在同一位置。
29.java基本数据类型
| 简单类型 |
boolean |
byte |
char |
short |
Int |
long |
float |
double |
void |
| 二进制位数 |
1 |
8 |
16 |
16 |
32 |
64 |
32 |
64 |
-- |
| 封装器类 |
Boolean |
Byte |
Character |
Short |
Integer |
Long |
Float |
Double |
Void |
30.hash冲突
开放地址法：
1.线性探测法:ThreadLocalMap
线性再散列法是形式最简单的处理冲突的方法。插入元素时，如果发生冲突，算法会简单的从该槽位置向后循环遍历hash表，直到找到表中的下一个空槽，并将该元素放入该槽中（会导致相同hash值的元素挨在一起和其他hash值对应的槽被占用）。查找元素时，首先散列值所指向的槽，如果没有找到匹配，则继续从该槽遍历hash表，直到：（1）找到相应的元素；（2）找到一个空槽，指示查找的元素不存在，（所以不能随便删除元素）；（3）整个hash表遍历完毕（指示该元素不存在并且hash表是满的）
用线性探测法处理冲突，思路清晰，算法简单，但存在下列缺点：
① 处理溢出需另编程序。一般可另外设立一个溢出表，专门用来存放上述哈希表中放不下的记录。此溢出表最简单的结构是顺序表，查找方法可用顺序查找。
② 按上述算法建立起来的哈希表，删除工作非常困难。如果将此元素删除，查找的时会发现空槽，则会认为要找的元素不存在。只能标上已被删除的标记，否则，将会影响以后的查找。
③ 线性探测法很容易产生堆聚现象。所谓堆聚现象，就是存入哈希表的记录在表中连成一片。按照线性探测法处理冲突，如果生成哈希地址的连续序列愈长 ( 即不同关键字值的哈希地址相邻在一起愈长 ) ，则当新的记录加入该表时，与这个序列发生冲突的可能性愈大。因此，哈希地址的较长连续序列比较短连续序列生长得快，这就意味着，一旦出现堆聚 ( 伴随着冲突 ) ，就将引起进一步的堆聚。
2.线性补偿探测法
线性补偿探测法的基本思想是：将线性探测的步长从 1 改为 Q ，即将上述算法中的
hash ＝ (hash ＋ 1) % m 改为：hash ＝ (hash ＋ Q) % m = hash % m + Q % m，而且要求 Q 与 m 是互质的，以便能探测到哈希表中的所有单元。
【例】 PDP-11 小型计算机中的汇编程序所用的符合表，就采用此方法来解决冲突，所用表长 m ＝ 1321 ，选用 Q ＝ 25 。
3.伪随机探测
随机探测的基本思想是：将线性探测的步长从常数改为随机数，即令： hash ＝ (hash ＋ RN) % m ，其中 RN 是一个随机数。在实际程序中应预先用随机数发生器产生一个随机序列，将此序列作为依次探测的步长。这样就能使不同的关键字具有不同的探测次序，从而可以避 免或减少堆聚。基于与线性探测法相同的理由，在线性补偿探测法和随机探测法中，删除一个记录后也要打上删除标记。
拉链法
拉链法 : hashmap
拉链法的优点
与开放定址法相比，拉链法有如下几个优点：
①拉链法处理冲突简单，且无堆积现象，即非同义词决不会发生冲突，因此平均查找长度较短；
②由于拉链法中各链表上的结点空间是动态申请的，故它更适合于造表前无法确定表长的情况；
③开放定址法为减少冲突，要求装填因子α较小，故当结点规模较大时会浪费很多空间。而拉链法中可取α≥1，且结点较大时，拉链法中增加的指针域可忽略不计，因此节省空间；
④在用拉链法构造的散列表中，删除结点的操作易于实现。只要简单地删去链表上相应的结点即可。
拉链法的缺点
拉链法的缺点是：指针需要额外的空间，故当结点规模较小时，开放定址法较为节省空间，而若将节省的指针空间用来扩大散列表的规模，可使装填因子变小，这又减少了开放定址法中的冲突，从而提高平均查找速度。
再散列（双重散列，多重散列）
当发生冲突时，使用第二个、第三个、哈希函数计算地址，直到无冲突时。缺点：计算时间增加。
建立一个公共溢出区
假设哈希函数的值域为[0,m-1],则设向量HashTable[0..m-1]为基本表，另外设立存储空间向量OverTable[0..v]用以存储发生冲突的记录。
31.java中异常
Throwable包含了错误(Error)和异常(Excetion两类)
Exception又包含了运行时异常(RuntimeException, 又叫非检查异常)和非运行时异常(又叫检查异常)
(1) Error是程序无法处理了, 如果OutOfMemoryError、OutOfMemoryError等等, 这些异常发生时, java虚拟机一般会终止线程 .
(2) 运行时异常都是RuntimeException类及其子类,如 NullPointerException、IndexOutOfBoundsException等, 这些异常是不检查的异常, 是在程序运行的时候可能会发生的, 所以程序可以捕捉, 也可以不捕捉. 这些错误一般是由程序的逻辑错误引起的, 程序应该从逻辑角度去尽量避免.
(3) 检查异常是运行时异常以外的异常, 也是Exception及其子类, 这些异常从程序的角度来说是必须经过捕捉检查处理的, 否则不能通过编译. 如IOException、SQLException等
32.浏览器访问网页过程
第一步，解析域名，找到主机IP
（1）浏览器会缓存DNS一段时间，一般2-30分钟不等。如果有缓存，直接返回IP，否则下一步。
（2）缓存中无法找到IP，浏览器会进行一个系统调用，查询hosts文件。如果找到，直接返回IP，否则下一步。（在计算机本地目录etc下有一个hosts文件，hosts文件中保存有域名与IP的对应解析，通常也可以修改hosts科学上网或破解软件。）
（3）进行了（1）（2）本地查询无果，只能借助于网络。路由器一般都会有自己的DNS缓存，ISP服务商DNS缓存，这时一般都能够得到相应的IP。如果还是无果，只能借助于DNS递归解析了。
（4）这时，ISP的DNS服务器就会开始从根域名服务器开始递归搜索，从.com顶级域名服务器，到baidu的域名服务器。
到这里，浏览器就获得了IP。在DNS解析过程中，常常会解析出不同的IP。比如，电信的是一个IP，网通的是另一个IP。这是采取了智能DNS的结果，降低运营商间访问延时，在多个运营商设置主机房，就近访问主机。电信用户返回电信主机IP，网通用户返回网通主机IP。当然，劫持DNS，也可以屏蔽掉一部分网点的访问，某防火长城也加入了这一特性。
浏览器利用IP直接与网站主机通信。浏览器发出TCP（SYN标志位为1）连接请求，主机返回TCP（SYN，ACK标志位均为1）应答报文，浏览器收到应答报文发现ACK标志位为1，表示连接请求确认。浏览器返回TCP（）确认报文，主机收到确认报文，三次握手，TCP链接建立完成。
浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL，也就是http://www.baidu.com/ ，还有User-Agent用户浏览器操作系统信息，编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip，压缩之后传输html文件。Cookies如果是首次访问，会提示服务器建立用户缓存信息，如果不是，可以利用Cookies对应键值，找到相应缓存，缓存里面存放着用户名，密码和一些用户设置项（Cookie是由服务器端生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用cookie）。Cookie名称和值可以由服务器端开发自己定义，对于JSP而言也可以直接写入jsessionid，这样服务器可以知道该用户是否合法用户以及是否需要重新登录等，服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态）。
第四部分，显示页面或返回其他
返回状态码200 OK，表示服务器可以相应请求，返回报文，由于在报头中Content-type为“text/html”，浏览器以HTML形式呈现，而不是下载文件。
但是，对于大型网站存在多个主机站点，往往不会直接返回请求页面，而是重定向。返回的状态码就不是200 OK，而是301,302以3开头的重定向码，浏览器在获取了重定向响应后，在响应报文中Location项找到重定向地址，浏览器重新第一步访问即可。
补充一点的就是，重定向是为了负载均衡或者导入流量，提高SEO排名。利用一个前端服务器接受请求，然后负载到不同的主机上，可以大大提高站点的业务并发处理能力；重定向也可将多个域名的访问，集中到一个站点；由于baidu.com，www.baidu.com会被搜索引擎认为是两个网站，照成每个的链接数都会减少从而降低排名，永久重定向会将两个地址关联起来，搜索引擎会认为是同一个网站，从而提高排名。
33.动态代理
动态代理在Java中有着广泛的应用，比如Spring AOP，Hibernate数据查询、测试框架的后端mock、RPC，Java注解对象获取等。静态代理的代理关系在编译时就确定了，而动态代理的代理关系是在编译期确定的。静态代理实现简单，适合于代理类较少且确定的情况，而动态代理则给我们提供了更大的灵活性。今天我们来探讨Java中两种常见的动态代理方式：JDK原生动态代理和CGLIB动态代理。
JDK原生动态代理
先从直观的示例说起，假设我们有一个接口Hello和一个简单实现HelloImp：
| 1 2 3 4 5 6 7 8 9 10 11 |
|
这是Java种再常见不过的场景，使用接口制定协议，然后用不同的实现来实现具体行为。假设你已经拿到上述类库，如果我们想通过日志记录对sayHello()的调用，使用静态代理可以这样做：
| 1 2 3 4 5 6 7 8 9 10 |
|
上例中静态代理类StaticProxiedHello作为HelloImp的代理，实现了相同的Hello接口。用Java动态代理可以这样做：
- 首先实现一个InvocationHandler，方法调用会被转发到该类的invoke()方法。
- 然后在需要使用Hello的时候，通过JDK动态代理获取Hello的代理对象。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
运行上述代码输出结果：
| 1 2 |
|
上述代码的关键是Proxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler handler)方法，该方法会根据指定的参数动态创建代理对象。三个参数的意义如下：
loader，指定代理对象的类加载器；interfaces，代理对象需要实现的接口，可以同时指定多个接口；handler，方法调用的实际处理者，代理对象的方法调用都会转发到这里（*注意1）。
newProxyInstance()会返回一个实现了指定接口的代理对象，对该对象的所有方法调用都会转发给InvocationHandler.invoke()方法。理解上述代码需要对Java反射机制有一定了解。动态代理神奇的地方就是：
- 代理对象是在程序运行时产生的，而不是编译期；
- 对代理对象的所有接口方法调用都会转发到
InvocationHandler.invoke()方法，在invoke()方法里我们可以加入任何逻辑，比如修改方法参数，加入日志功能、安全检查功能等；之后我们通过某种方式执行真正的方法体，示例中通过反射调用了Hello对象的相应方法，还可以通过RPC调用远程方法。
注意1：对于从Object中继承的方法，JDK Proxy会把
hashCode()、equals()、toString()这三个非接口方法转发给InvocationHandler，其余的Object方法则不会转发。详见JDK Proxy官方文档。
如果对JDK代理后的对象类型进行深挖，可以看到如下信息：
| 1 2 3 4 5 6 |
|
代理对象的类型是jdkproxy.$Proxy0，这是个动态生成的类型，类名是形如$ProxyN的形式；父类是java.lang.reflect.Proxy，所有的JDK动态代理都会继承这个类；同时实现了Hello接口，也就是我们接口列表中指定的那些接口。
如果你还对jdkproxy.$Proxy0具体实现感兴趣，它大致长这个样子：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
这些逻辑没什么复杂之处，但是他们是在运行时动态产生的，无需我们手动编写。更多详情，可参考BrightLoong的Java静态代理&动态代理笔记
Java动态代理为我们提供了非常灵活的代理机制，但Java动态代理是基于接口的，如果对象没有实现接口我们该如何代理呢？CGLIB登场。
CGLIB动态代理
CGLIB(Code Generation Library)是一个基于ASM的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成。CGLIB通过继承方式实现代理。
来看示例，假设我们有一个没有实现任何接口的类HelloConcrete：
| 1 2 3 4 5 |
|
因为没有实现接口该类无法使用JDK代理，通过CGLIB代理实现如下：
- 首先实现一个MethodInterceptor，方法调用会被转发到该类的intercept()方法。
- 然后在需要使用HelloConcrete的时候，通过CGLIB动态代理获取代理对象。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
运行上述代码输出结果：
| 1 2 |
|
上述代码中，我们通过CGLIB的Enhancer来指定要代理的目标对象、实际处理代理逻辑的对象，最终通过调用create()方法得到代理对象，对这个对象所有非final方法的调用都会转发给MethodInterceptor.intercept()方法，在intercept()方法里我们可以加入任何逻辑，比如修改方法参数，加入日志功能、安全检查功能等；通过调用MethodProxy.invokeSuper()方法，我们将调用转发给原始对象，具体到本例，就是HelloConcrete的具体方法。CGLIG中MethodInterceptor的作用跟JDK代理中的InvocationHandler很类似，都是方法调用的中转站。
注意：对于从Object中继承的方法，CGLIB代理也会进行代理，如
hashCode()、equals()、toString()等，但是getClass()、wait()等方法不会，因为它是final方法，CGLIB无法代理。
如果对CGLIB代理之后的对象类型进行深挖，可以看到如下信息：
| 1 2 3 4 5 6 |
|
我们看到使用CGLIB代理之后的对象类型是cglib.HelloConcrete$$EnhancerByCGLIB$$e3734e52，这是CGLIB动态生成的类型；父类是HelloConcrete，印证了CGLIB是通过继承实现代理；同时实现了net.sf.cglib.proxy.Factory接口，这个接口是CGLIB自己加入的，包含一些工具方法。
注意，既然是继承就不得不考虑final的问题。我们知道final类型不能有子类，所以CGLIB不能代理final类型，遇到这种情况会抛出类似如下异常：
| 1 |
|
同样的，final方法是不能重载的，所以也不能通过CGLIB代理，遇到这种情况不会抛异常，而是会跳过final方法只代理其他方法。
如果你还对代理类cglib.HelloConcrete$$EnhancerByCGLIB$$e3734e52具体实现感兴趣，它大致长这个样子：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
上述代码我们看到，当调用代理对象的sayHello()方法时，首先会尝试转发给MethodInterceptor.intercept()方法，如果没有MethodInterceptor就执行父类的sayHello()。这些逻辑没什么复杂之处，但是他们是在运行时动态产生的，无需我们手动编写。如何获取CGLIB代理类字节码可参考Access the generated byte[] array directly。
更多关于CGLIB的介绍可以参考Rafael Winterhalter的cglib: The missing manual，一篇很深入的文章。
结语
本文介绍了Java两种常见动态代理机制的用法和原理，JDK原生动态代理是Java原生支持的，不需要任何外部依赖，但是它只能基于接口进行代理；CGLIB通过继承的方式进行代理，无论目标对象有没有实现接口都可以代理，但是无法处理final的情况。
动态代理是Spring AOP(Aspect Orient Programming, 面向切面编程)的实现方式，了解动态代理原理，对理解Spring AOP大有帮助。
34.hashmap死锁
问题的症状
从前我们的Java代码因为一些原因使用了HashMap这个东西，但是当时的程序是单线程的，一切都没有问题。后来，我们的程序性能有问题，所以需要变成多线程的，于是，变成多线程后到了线上，发现程序经常占了100%的CPU，查看堆栈，你会发现程序都Hang在了HashMap.get()这个方法上了，重启程序后问题消失。但是过段时间又会来。而且，这个问题在测试环境里可能很难重现。
我们简单的看一下我们自己的代码，我们就知道HashMap被多个线程操作。而Java的文档说HashMap是非线程安全的，应该用ConcurrentHashMap。
但是在这里我们可以来研究一下原因。
Hash表数据结构
我需要简单地说一下HashMap这个经典的数据结构。
HashMap通常会用一个指针数组（假设为table[]）来做分散所有的key，当一个key被加入时，会通过Hash算法通过key算出这个数组的下标i，然后就把这个<key, value>插到table[i]中，如果有两个不同的key被算在了同一个i，那么就叫冲突，又叫碰撞，这样会在table[i]上形成一个链表。
我们知道，如果table[]的尺寸很小，比如只有2个，如果要放进10个keys的话，那么碰撞非常频繁，于是一个O(1)的查找算法，就变成了链表遍历，性能变成了O(n)，这是Hash表的缺陷（可参看《Hash Collision DoS 问题》）。
所以，Hash表的尺寸和容量非常的重要。一般来说，Hash表这个容器当有数据要插入时，都会检查容量有没有超过设定的thredhold，如果超过，需要增大Hash表的尺寸，但是这样一来，整个Hash表里的无素都需要被重算一遍。这叫rehash，这个成本相当的大。
相信大家对这个基础知识已经很熟悉了。
HashMap的rehash源代码
下面，我们来看一下Java的HashMap的源代码。
Put一个Key,Value对到Hash表中：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
检查容量是否超标
| 1 2 3 4 5 6 7 8 |
|
新建一个更大尺寸的hash表，然后把数据从老的Hash表中迁移到新的Hash表中。
| 1 2 3 4 5 6 7 8 9 10 11 12 |
|
迁移的源代码，注意高亮处：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
好了，这个代码算是比较正常的。而且没有什么问题。
正常的ReHash的过程
画了个图做了个演示。
- 我假设了我们的hash算法就是简单的用key mod 一下表的大小（也就是数组的长度）。
- 最上面的是old hash 表，其中的Hash表的size=2, 所以key = 3, 7, 5，在mod 2以后都冲突在table[1]这里了。
- 接下来的三个步骤是Hash表 resize成4，然后所有的<key,value> 重新rehash的过程
并发下的Rehash
1）假设我们有两个线程。我用红色和浅蓝色标注了一下。
我们再回头看一下我们的 transfer代码中的这个细节：
| 1 2 3 4 5 6 7 |
|
而我们的线程二执行完成了。于是我们有下面的这个样子。
注意，因为Thread1的 e 指向了key(3)，而next指向了key(7)，其在线程二rehash后，指向了线程二重组后的链表。我们可以看到链表的顺序被反转后。
2）线程一被调度回来执行。
- 先是执行 newTalbe[i] = e;
- 然后是e = next，导致了e指向了key(7)，
- 而下一次循环的next = e.next导致了next指向了key(3)
3）一切安好。
线程一接着工作。把key(7)摘下来，放到newTable[i]的第一个，然后把e和next往下移。
4）环形链接出现。
e.next = newTable[i] 导致 key(3).next 指向了 key(7)
注意：此时的key(7).next 已经指向了key(3)， 环形链表就这样出现了。
于是，当我们的线程一调用到，HashTable.get(11)时，悲剧就出现了——Infinite Loop。
35.Collection接口
1.1 Collection接口：
Collection接口——定义了存取一组对象的方法，其子接口Set和List分别定义了存储方式。
（1）Set中的数据对象没有顺序且不可以重复。
（2）List中的数据对象有顺序且可以重复。
Collection接口所定义的方法：
| 方法 |
描述 |
| Boolean add(Object o) |
向集合中添加一个对象的引用 |
| Void clear() |
删除集合中的所有对象，即不再持有这些对象的引用 |
| Boolean contains(Object o) |
判断在集合中是否持有特定对象的引用 |
| Boolean isEmpty() |
判断集合是否为空 |
| Iterator iterator() |
返回一个Iterator对象，可用它来遍历集合中的元素 |
| Boolean remove(Object o) |
从集合中删除一个对象的引用 |
| Boolean retainAll(Collection<?> c) |
保留集合中的指定内容 |
| Int size() |
返回集合中元素的数目 |
| Object[] toArray() |
返回一个数组，该数组包含集合中的所有元素
|
| Boolean equals(Object o) |
对象比较 |
| Int hashCode() |
返回hash码 |
36.可以做GC Root的对象
- 虚拟机栈中的引用对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用对象
- 本地方法栈中JNI引用对象、
37.触发主GC（Garbage Collector，垃圾回收）的条件
（1）当应用程序空闲时，即没有应用线程在运行时，GC会被调用。
（2）Java堆内存不足时，GC会被调用。
38.说一下BIO/AIO/NIO 有什么区别？及异步模式的用途和意义
1F
说一说I/O
首先来说一下什么是I/O?
在计算机系统中I/O就是输入（Input）和输出(Output)的意思，针对不同的操作对象，可以划分为磁盘I/O模型，网络I/O模型，内存映射I/O, Direct I/O、数据库I/O等，只要具有输入输出类型的交互系统都可以认为是I/O系统，也可以说I/O是整个操作系统数据交换与人机交互的通道，这个概念与选用的开发语言没有关系，是一个通用的概念。
在如今的系统中I/O却拥有很重要的位置，现在系统都有可能处理大量文件，大量数据库操作，而这些操作都依赖于系统的I/O性能，也就造成了现在系统的瓶颈往往都是由于I/O性能造成的。因此，为了解决磁盘I/O性能慢的问题，系统架构中添加了缓存来提高响应速度；或者有些高端服务器从硬件级入手，使用了固态硬盘（SSD）来替换传统机械硬盘；在大数据方面，Spark越来越多的承担了实时性计算任务，而传统的Hadoop体系则大多应用在了离线计算与大量数据存储的场景，这也是由于磁盘I/O性能远不如内存I/O性能而造成的格局（Spark更多的使用了内存，而MapReduece更多的使用了磁盘）。因此，一个系统的优化空间，往往都在低效率的I/O环节上，很少看到一个系统CPU、内存的性能是其整个系统的瓶颈。也正因为如此，Java在I/O上也一直在做持续的优化，从JDK 1.4开始便引入了NIO模型，大大的提高了以往BIO模型下的操作效率。
这里先给出BIO、NIO、AIO的基本定义与类比描述：
-
BIO （Blocking I/O）：同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。这里使用那个经典的烧开水例子，这里假设一个烧开水的场景，有一排水壶在烧开水，BIO的工作模式就是， 叫一个线程停留在一个水壶那，直到这个水壶烧开，才去处理下一个水壶。但是实际上线程在等待水壶烧开的时间段什么都没有做。
-
NIO （New I/O）：同时支持阻塞与非阻塞模式，但这里我们以其同步非阻塞I/O模式来说明，那么什么叫做同步非阻塞？如果还拿烧开水来说，NIO的做法是叫一个线程不断的轮询每个水壶的状态，看看是否有水壶的状态发生了改变，从而进行下一步的操作。
-
AIO （ Asynchronous I/O）：异步非阻塞I/O模型。异步非阻塞与同步非阻塞的区别在哪里？异步非阻塞无需一个线程去轮询所有IO操作的状态改变，在相应的状态改变后，系统会通知对应的线程来处理。对应到烧开水中就是，为每个水壶上面装了一个开关，水烧开之后，水壶会自动通知我水烧开了。
进程中的IO调用步骤大致可以分为以下四步：
-
进程向操作系统请求数据 ;
-
操作系统把外部数据加载到内核的缓冲区中;
-
操作系统把内核的缓冲区拷贝到进程的缓冲区 ;
-
进程获得数据完成自己的功能 ;
当操作系统在把外部数据放到进程缓冲区的这段时间（即上述的第二，三步），如果应用进程是挂起等待的，那么就是同步IO，反之，就是异步IO，也就是AIO 。
2F
BIO（Blocking I/O）同步阻塞I/O
这是最基本与简单的I/O操作方式，其根本特性是做完一件事再去做另一件事，一件事一定要等前一件事做完，这很符合程序员传统的顺序来开发思想，因此BIO模型程序开发起来较为简单，易于把握。
但是BIO如果需要同时做很多事情（例如同时读很多文件，处理很多tcp请求等），就需要系统创建很多线程来完成对应的工作，因为BIO模型下一个线程同时只能做一个工作，如果线程在执行过程中依赖于需要等待的资源，那么该线程会长期处于阻塞状态，我们知道在整个操作系统中，线程是系统执行的基本单位，在BIO模型下的线程 阻塞就会导致系统线程的切换，从而对整个系统性能造成一定的影响。当然如果我们只需要创建少量可控的线程，那么采用BIO模型也是很好的选择，但如果在需要考虑高并发的web或者tcp服务器中采用BIO模型就无法应对了，如果系统开辟成千上万的线程，那么CPU的执行时机都会浪费在线程的切换中，使得线程的执行效率大大降低。此外，关于线程这里说一句题外话，在系统开发中线程的生命周期一定要准确控制，在需要一定规模并发的情形下，尽量使用线程池来确保线程创建数目在一个合理的范围之内，切莫编写线程数量创建上限的代码。
3F
NIO (New I/O) 同步非阻塞I/O
关于NIO，国内有很多技术博客将英文翻译成No-Blocking I/O，非阻塞I/O模型 ，当然这样就与BIO形成了鲜明的特性对比。NIO本身是基于事件驱动的思想来实现的，其目的就是解决BIO的大并发问题，在BIO模型中，如果需要并发处理多个I/O请求，那就需要多线程来支持，NIO使用了多路复用器机制，以socket使用来说，多路复用器通过不断轮询各个连接的状态，只有在socket有流可读或者可写时，应用程序才需要去处理它，在线程的使用上，就不需要一个连接就必须使用一个处理线程了，而是只是有效请求时（确实需要进行I/O处理时），才会使用一个线程去处理，这样就避免了BIO模型下大量线程处于阻塞等待状态的情景。
相对于BIO的流，NIO抽象出了新的通道（Channel）作为输入输出的通道，并且提供了缓存（Buffer）的支持，在进行读操作时，需要使用Buffer分配空间，然后将数据从Channel中读入Buffer中，对于Channel的写操作，也需要现将数据写入Buffer，然后将Buffer写入Channel中。
如下是NIO方式进行文件拷贝操作的示例，见下图：
通过比较New IO的使用方式我们可以发现，新的IO操作不再面向 Stream来进行操作了，改为了通道Channel，并且使用了更加灵活的缓存区类Buffer，Buffer只是缓存区定义接口， 根据需要，我们可以选择对应类型的缓存区实现类。在java NIO编程中，我们需要理解以下3个对象Channel、Buffer和Selector。
-
Channel
首先说一下Channel，国内大多翻译成“通道”。Channel和IO中的Stream(流)是差不多一个等级的。只不过Stream是单向的，譬如：InputStream, OutputStream。而Channel是双向的，既可以用来进行读操作，又可以用来进行写操作，NIO中的Channel的主要实现有：FileChannel、DatagramChannel、SocketChannel、ServerSocketChannel；通过看名字就可以猜出个所以然来：分别可以对应文件IO、UDP和TCP（Server和Client）。
-
Buffer
NIO中的关键Buffer实现有：ByteBuffer、CharBuffer、DoubleBuffer、 FloatBuffer、IntBuffer、 LongBuffer,、ShortBuffer，分别对应基本数据类型: byte、char、double、 float、int、 long、 short。当然NIO中还有MappedByteBuffer, HeapByteBuffer, DirectByteBuffer等这里先不具体陈述其用法细节。
说一下 DirectByteBuffer 与 HeapByteBuffer 的区别？
它们 ByteBuffer 分配内存的两种方式。HeapByteBuffer 顾名思义其内存空间在 JVM 的 heap（堆）上分配，可以看做是 jdk 对于 byte[] 数组的封装；而 DirectByteBuffer 则直接利用了系统接口进行内存申请，其内存分配在c heap 中，这样就减少了内存之间的拷贝操作，如此一来，在使用 DirectByteBuffer 时，系统就可以直接从内存将数据写入到 Channel 中，而无需进行 Java 堆的内存申请，复制等操作，提高了性能。既然如此，为什么不直接使用 DirectByteBuffer，还要来个 HeapByteBuffer？原因在于， DirectByteBuffer 是通过full gc来回收内存的，DirectByteBuffer会自己检测情况而调用 system.gc()，但是如果参数中使用了 DisableExplicitGC 那么就无法回收该快内存了，-XX:+DisableExplicitGC标志自动将 System.gc() 调用转换成一个空操作，就是应用中调用 System.gc() 会变成一个空操作，那么如果设置了就需要我们手动来回收内存了，所以DirectByteBuffer使用起来相对于完全托管于 java 内存管理的Heap ByteBuffer 来说更复杂一些，如果用不好可能会引起OOM。Direct ByteBuffer 的内存大小受 -XX:MaxDirectMemorySize JVM 参数控制（默认大小64M），在 DirectByteBuffer 申请内存空间达到该设置大小后，会触发 Full GC。
-
Selector
Selector 是NIO相对于BIO实现多路复用的基础，Selector 运行单线程处理多个 Channel，如果你的应用打开了多个通道，但每个连接的流量都很低，使用 Selector 就会很方便。例如在一个聊天服务器中。要使用 Selector , 得向 Selector 注册 Channel，然后调用它的 select() 方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新的连接进来、数据接收等。
这里我们再来看一个NIO模型下的TCP服务器的实现，我们可以看到Selector 正是NIO模型下 TCP Server 实现IO复用的关键，请仔细理解下段代码while循环中的逻辑，见下图：
4F
AIO (Asynchronous I/O) 异步非阻塞I/O
Java AIO就是Java作为对异步IO提供支持的NIO.2 ，Java NIO2 (JSR 203)定义了更多的 New I/O APIs， 提案2003提出，直到2011年才发布， 最终在JDK 7中才实现。JSR 203除了提供更多的文件系统操作API(包括可插拔的自定义的文件系统)， 还提供了对socket和文件的异步 I/O操作。 同时实现了JSR-51提案中的socket channel全部功能,包括对绑定， option配置的支持以及多播multicast的实现。
从编程模式上来看AIO相对于NIO的区别在于，NIO需要使用者线程不停的轮询IO对象，来确定是否有数据准备好可以读了，而AIO则是在数据准备好之后，才会通知数据使用者，这样使用者就不需要不停地轮询了。当然AIO的异步特性并不是Java实现的伪异步，而是使用了系统底层API的支持，在Unix系统下，采用了epoll IO模型，而windows便是使用了IOCP模型。关于Java AIO，本篇只做一个抛砖引玉的介绍，如果你在实际工作中用到了，那么可以参考Netty在高并发下使用AIO的相关技术。
总 结
IO实质上与线程没有太多的关系，但是不同的IO模型改变了应用程序使用线程的方式，NIO与AIO的出现解决了很多BIO无法解决的并发问题，当然任何技术抛开适用场景都是耍流氓，复杂的技术往往是为了解决简单技术无法解决的问题而设计的，在系统开发中能用常规技术解决的问题，绝不用复杂技术，否则大大增加系统代码的维护难度，学习IT技术不是为了炫技，而是要实实在在解决问题。
40.select、poll和epoll之间的区别与优缺点
I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。select，poll，epoll都是IO多路复用的机制。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。下来，分别谈谈。
select——>
原理概述：
select 的核心功能是调用tcp文件系统的poll函数，不停的查询，如果没有想要的数据，主动执行一次调度（防止一直占用cpu），直到有一个连接有想要的消息为止。从这里可以看出select的执行方式基本就是不同的调用poll,直到有需要的消息为止。
缺点：
1、每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大；
2、同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大；
3、select支持的文件描述符数量太小了，默认是1024。
优点：
1、select的可移植性更好，在某些Unix系统上不支持poll()。
2、select对于超时值提供了更好的精度：微秒，而poll是毫秒。
poll——>
原理概述：
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
缺点：
1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义；
2、与select一样，poll返回后，需要轮询pollfd来获取就绪的描述符。
优点：
1、poll() 不要求开发者计算最大文件描述符加一的大小。
2、poll() 在应付大数目的文件描述符的时候速度更快，相比于select。
3、它没有最大连接数的限制，原因是它是基于链表来存储的。
epoll——>
原理概述：
epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时， 返回的不是实际的描述符，而是一个代表就绪描述符数量的值，你只需要去epoll指定的一 个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射技术，这 样便彻底省掉了这些文件描述符在系统调用时复制的开销。
epoll的优点就是改进了前面所说缺点：
1、支持一个进程打开大数目的socket描述符：相比select，epoll则没有对FD的限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
2、IO效率不随FD数目增加而线性下降：epoll不存在这个问题，它只会对"活跃"的socket进行操作--- 这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
3、使用mmap加速内核与用户空间的消息传递：这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就 很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。
三者对比与区别：
1、select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
2、select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
41.http版本的区别
http1.0和1.1的区别
l 1.1默认长连接
l 1.1可以不带body信息，节约带宽
l 支持host域（虚拟站点可供用ip）
http1.1和1.2的区别
l 多路复用
l 数据压缩（报文头）
l 服务器推送
l 二进制格式传输
42.beanfactory和applicationcontext是什么关系
首先两者加载Bean的方式都是通过Xml配置文件，ApplicationContext和BeanFacotry相比，提供了更多的扩展功能，但是这还不是主要区别，主要区别在于BeanFacotry是延迟加载，举个例子：如果Bean没有完全注入，BeanFacotry加载后，会在你第一次调用GetBean方法才会抛出异常；而ApplicationContext会在初始化的时候就加载并且检查，这样的好处是可以及时检查依赖是否完全注入；所以通常来说我们会选择使用ApplicationContext。</p><p>BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。
BeanFacotry是Spring中相当古老的Factory了，比如说Xml BeanFactory就是一种相当典型的BeanFactory。所以原始的BeanFactory就无法支持诸如AOP、Web应用等许多插件。
ApplicationContext接口是由BeanFactory接口派生出来的，所以提供了BeanFactory的所有功能。ApplicationContext是一种更加面向框架的工作方式以及对上下文进行分层和实现继承。并且ApplicationContext还额外的提供了以下功能：
• MessageSource，提供国际化的消息访问；
• 资源访问，如URL和文件；
• 事件传播；
• 载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的Web层。
43.CAP、
是误解，一般来说 P 是前提。所以基本是CA里选，不是任意3选2.
为什么呢？
P 意指分区容忍性。 这个分区容忍性什么意思，很多人容易望文生义，不要见风就是雨，理解成别的什么意思。所谓分区指的是网络分区的意思，这个一样还是容易望文生义。详细一点解释，比如你有A B两台服务器，它们之间是有通信的，突然，不知道为什么，它们之间的网络链接断掉了。好了，那么现在本来AB在同一个网络现在发生了网络分区，变成了A所在的A网络和B所在的B网络。所谓的分区容忍性，就是说一个数据服务的多台服务器在发生了上述情况的时候，依然能继续提供服务。
所以显而易见的，P是大前提，如果P发生了，咱们的数据服务直接不服务了，还谈个毛的可用性和一致性呢。
因此CAP要解释成，当P发生的时候，A和C只能而选一。
举个简单的例子，A服务器B服务器同步数据，现在A B之间网络断掉了，那么现在发来A一个写入请求，但是B却没有相关的请求，显然，如果A不写，保持一致性，那么我们就失去了A的服务，但是如果A写了，跟B的数据就不一致了，我们自然就丧失了一致性。
这里设计就涉及到架构师的选择了。注意这里的一致性是强一致性，意思是AB的数据时刻都是同步的，如果我们放弃了强一致性，不代表我们的数据就是一定是不一致的了，我们可以让A先写入本地，等到通信恢复了再同步给B，这就是所谓的最终一致性，长远的看我们的数据还是一致的，我们只是在某一个时间窗口里数据不一致罢了。如果这个时间窗口小过了用户逻辑处理的时间。那么其实对于用户来说根本毛都感觉不到。
最终一致性有个很有意思的协议叫gossip就跟传八卦一个意思，我就把我收到里信息里我本地没有的部分加到我本地，再把这个信息发出去，那么长远的看，网络时好时坏，但是最终所有人都会有所有的信息。因此我们还是能够保证数据的最终一致性的。
综上，CAP应该描述成，当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。
44.匿名内部类 是否可以继承其它类,是否可以实现接口
https://www.zhihu.com/question/21285716/answer/121231900
45.序列化和反序列化
一、序列化和反序列化的概念
把对象转换为字节序列的过程称为对象的序列化。
把字节序列恢复为对象的过程称为对象的反序列化。
对象的序列化主要有两种用途：
1） 把对象的字节序列永久地保存到硬盘上，通常存放在一个文件中；
2） 在网络上传送对象的字节序列。
在很多应用中，需要对某些对象进行序列化，让它们离开内存空间，入住物理硬盘，以便长期保存。比如最常见的是Web服务器中的Session对象，当有 10万用户并发访问，就有可能出现10万个Session对象，内存可能吃不消，于是Web容器就会把一些seesion先序列化到硬盘中，等要用了，再把保存在硬盘中的对象还原到内存中。
当两个进程在进行远程通信时，彼此可以发送各种类型的数据。无论是何种类型的数据，都会以二进制序列的形式在网络上传送。发送方需要把这个Java对象转换为字节序列，才能在网络上传送；接收方则需要把字节序列再恢复为Java对象。
二、JDK类库中的序列化API
java.io.ObjectOutputStream代表对象输出流，它的writeObject(Object obj)方法可对参数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。
java.io.ObjectInputStream代表对象输入流，它的readObject()方法从一个源输入流中读取字节序列，再把它们反序列化为一个对象，并将其返回。
只有实现了Serializable和Externalizable接口的类的对象才能被序列化。Externalizable接口继承自 Serializable接口，实现Externalizable接口的类完全由自身来控制序列化的行为，而仅实现Serializable接口的类可以 采用默认的序列化方式 。
对象序列化包括如下步骤：
1） 创建一个对象输出流，它可以包装一个其他类型的目标输出流，如文件输出流；
2） 通过对象输出流的writeObject()方法写对象。
对象反序列化的步骤如下：
1） 创建一个对象输入流，它可以包装一个其他类型的源输入流，如文件输入流；
2） 通过对象输入流的readObject()方法读取对象。
2,什么情况下需要序列化
当你想把的内存中的对象状态保存到一个文件中或者数据库中时候；
当你想用套接字在网络上传送对象的时候；
当你想通过RMI传输对象的时候；
46.软中断和硬中断
硬中断：
1. 硬中断是由硬件产生的，比如，像磁盘，网卡，键盘，时钟等。每个设备或设备集都有它自己的IRQ（中断请求）。基于IRQ，CPU可以将相应的请求分发到对应的硬件驱动上（注：硬件驱动通常是内核中的一个子程序，而不是一个独立的进程）。
2. 处理中断的驱动是需要运行在CPU上的，因此，当中断产生的时候，CPU会中断当前正在运行的任务，来处理中断。在有多核心的系统上，一个中断通常只能中断一颗CPU（也有一种特殊的情况，就是在大型主机上是有硬件通道的，它可以在没有主CPU的支持下，可以同时处理多个中断。）。
3. 硬中断可以直接中断CPU。它会引起内核中相关的代码被触发。对于那些需要花费一些时间去处理的进程，中断代码本身也可以被其他的硬中断中断。
4. 对于时钟中断，内核调度代码会将当前正在运行的进程挂起，从而让其他的进程来运行。它的存在是为了让调度代码（或称为调度器）可以调度多任务。
软中断：
1. 软中断的处理非常像硬中断。然而，它们仅仅是由当前正在运行的进程所产生的。
2. 通常，软中断是一些对I/O的请求。这些请求会调用内核中可以调度I/O发生的程序。对于某些设备，I/O请求需要被立即处理，而磁盘I/O请求通常可以排队并且可以稍后处理。根据I/O模型的不同，进程或许会被挂起直到I/O完成，此时内核调度器就会选择另一个进程去运行。I/O可以在进程之间产生并且调度过程通常和磁盘I/O的方式是相同。
3. 软中断仅与内核相联系。而内核主要负责对需要运行的任何其他的进程进行调度。一些内核允许设备驱动的一些部分存在于用户空间，并且当需要的时候内核也会调度这个进程去运行。
4. 软中断并不会直接中断CPU。也只有当前正在运行的代码（或进程）才会产生软中断。这种中断是一种需要内核为正在运行的进程去做一些事情（通常为I/O）的请求。有一个特殊的软中断是Yield调用，它的作用是请求内核调度器去查看是否有一些其他的进程可以运行。
问题解答：
1. 问：对于软中断，I/O操作是否是由内核中的I/O设备驱动程序完成？
答：对于I/O请求，内核会将这项工作分派给合适的内核驱动程序，这个程序会对I/O进行队列化，以可以稍后处理（通常是磁盘I/O），或如果可能可以立即执行它。通常，当对硬中断进行回应的时候，这个队列会被驱动所处理。当一个I/O请求完成的时候，下一个在队列中的I/O请求就会发送到这个设备上。
2. 问：软中断所经过的操作流程是比硬中断的少吗？换句话说，对于软中断就是：进程 ->内核中的设备驱动程序；对于硬中断：硬件->CPU->内核中的设备驱动程序？
答：是的，软中断比硬中断少了一个硬件发送信号的步骤。产生软中断的进程一定是当前正在运行的进程，因此它们不会中断CPU。但是它们会中断调用代码的流程。
如果硬件需要CPU去做一些事情，那么这个硬件会使CPU中断当前正在运行的代码。而后CPU会将当前正在运行进程的当前状态放到堆栈（stack）中，以至于之后可以返回继续运行。这种中断可以停止一个正在运行的进程；可以停止正处理另一个中断的内核代码；或者可以停止空闲进程。