一问一答之基础

参照这篇文章

Java部分

谈谈Java的优势

• 面向对象（相较于C的面向过程）
• 核心类库丰富
• 跨平台。一次编写，到处运行
• 内存管理（JVM）。和上一部分都是依赖于Java虚拟机（JVM）程序员不需要去关心操作系统带来的差异，不需要关心内存分配与回收

JVM,JRE,JDK之间的关系

Java文件执行过程

Java源码 —> 编译器 —> 字节码文件class —> 再JVM中解释 —> 机器可执行的二进制机器码 —> 程序运行

数据类型

基本数据和引用数据

基本有8种按占用内存分别为，byte(1),boolean(1),short(2),char(2),int(4),float(4),long(8),double(8)

访问权限

面向对象与面向过程的区别

面向过程：性能高，适用于单片机，嵌入式开发，Linux/unix，比较看重性能，缺点就是难维护，扩展与复用

面向对象：上面的反过来

面向过程强调一步步的过程实现，流程化的解决问题，面向对象是抽象的，只需要使用就可以，不需要关心是怎么去实现的

反射应用场景

• 框架（spring通过xml装载bean）
• jdbc
• BeanUtils.copyPropeties

OSI模型

三次握手

一句话：确保双方的一个收发数据的能力

A发给B，B收到了，B知道了自己的的收数据能力和A的发数据能力是可以的

B发给A，A收到了，A知道了B的发数据与自己的收数据能力

而此时B还不知道自己的发件和A的收件能力，所以A还会给B再发送一次

总之就是AB都需要确保四点，我的发送，我的接收，他的发送，他的接收

为什么是4次挥手

3次只是表明我同意你关闭连接了，但还不确定是否还有剩余的数据需要发送

DNS解析过程是什么

缓存 —> 本地hosts —> LDNS —> RDNS

1. 首先去浏览器缓存中寻找，如果缓存中有，则解析停止
2. 如果1没有则去操作系统本身去做域名解析，windows的路径（C:\Windows\System32\drivers\etc\hosts）
3. 向本地域名解析器（LDNS）发起域名请求，在win中可以通过ipconfig/all 查询。LDNS一般保存了大部分的解析结果，缓存时间受到域名失效时间控制，LDNS负责了大部分的解析工作
4. 如果还没有解析，转向根域名解析服务器（RDNS），它返回通用顶级域名解析服务器（gTDL）的地址（返回给LDNS）
5. LDNS向返回的这个地址发请求
6. 接受请求的gTLD查找并返回这个域名对应的Name Server的地址，这个Name Server就是网站注册的域名服务器
7. Name Server根据映射关系表找到目标ip，返回给LDNS
8. LDNS缓存这个域名和对应的ip
9. LDNS把解析的结果返回给用户，用户根据TTL值缓存到本地系统缓存中，域名解析过程至此结束

CDN原理

内容分发网络（Content Delivery Network），通过网络发到最靠近用户的节点，访问的时候可以就近获取，加快访问速度，如同迅雷的种子链接

通过给源站添加CNAME别名，向源站发送请求，会通过dns解析访问CNAME域名，调用加速节点的域名

String为什么被final修饰

• 线程安全。共享相同变量，简化多线程编程，提高性能
• 缓存利用。在创建的时候也缓存了hashcode，不需要重新计算。

集合部分

Collection接口主要由List、Set和Queue实现

聊聊List

常见的实现类有ArrayList和LinkedList，开发中常用的时ArrayList，底层结构是数组，另一个是链表

直接用数组不行？为什么要用ArrayList

数组需要指定大小，而ArrayList可以进行动态扩容。

怎么进行扩容

grow方法，每一次扩之前的1.5倍，扩完会利用arraycopy进行拷贝

为什么日常不用LinkedList而是ArrayList

由底层的数据结构决定，平时遍历比增删元素要多
而且ArrayList增删也进行过优化，在尾部增删的时间复杂度在O（1），速度也不会比LinkedList慢

说说CopyOnWriteArrayList

不在上面直接修改，而是创建一个副本进行修改，这种机制保证了读取不会受到写的干扰

适合于高并发读，读不会上锁

缺点：

1. 写操作消耗内存，原数组内容比较多的情况下会young gc或者full gc
2. 不能实时读，能做到最终一致性，不能满足实时一致性

public boolean add(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        newElements[len] = e;
        setArray(newElements);
        return true;
    } finally {
        lock.unlock();
    }
}

说说ArrayList

底层由数组实现，默认容量10，初始为一个空数组，在添加元素的时候才会为其扩容，即扩为10。如果容量不够，则会触发grow()进行扩容，grow是扩容的核心方法，将新容量扩为之前的1.5倍

private void grow(int minCapacity) {
    // oldCapacity为旧容量，newCapacity为新容量
    int oldCapacity = elementData.length;
    //将oldCapacity 右移一位，其效果相当于oldCapacity /2，
    //我们知道位运算的速度远远快于整除运算，整句运算式的结果就是将新容量更新为旧容量的1.5倍，
    int newCapacity = oldCapacity + (oldCapacity >> 1);
    //然后检查新容量是否大于最小需要容量，若还是小于最小需要容量，那么就把最小需要容量当作数组的新容量，
    if (newCapacity - minCapacity < 0)
        newCapacity = minCapacity;
    // 如果新容量大于 MAX_ARRAY_SIZE,进入(执行) `hugeCapacity()` 方法来比较 minCapacity 和 MAX_ARRAY_SIZE，
    //如果minCapacity大于最大容量，则新容量则为`Integer.MAX_VALUE`，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 `Integer.MAX_VALUE - 8`。
    if (newCapacity - MAX_ARRAY_SIZE > 0)
        newCapacity = hugeCapacity(minCapacity);
    // minCapacity is usually close to size, so this is a win:
    elementData = Arrays.copyOf(elementData, newCapacity);
}

什么是集合快速失败“fail-fast”？

多线程操作，在用增强for循环，其实就是集合的迭代器遍历时，如果同时进行遍历修改，就会抛出ConcurrentModificationException异常

原因：ArrayList的父类AbstarctList中有一个modCount变量，每次对集合进行修改时都会modCount++。ArrayList的Iterator中有一个expectedModCount变量，该变量会初始化和modCount相等，每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount的值和expectedmodCount的值是否相等，如果集合进行增删操作，modCount变量就会改变，就会造成expectedModCount!=modCount，此时就会抛出ConcurrentModificationException异常

解决方式

• 使用普通for循环
• 使用Java8的stream流
• 使用CopyOnWriteArrayList（在copy的数据上修改不会影响原数据）

ArrayList 和 LinkedList 的区别？

• 数据结构不同。A是动态数组数据结构进行实现，L是双向链表的方式实现
• 查询插入效率不同。A的查询效率高，插入删除低，L次之
• 占用内存不同。L更占内存，除了存数据还存向前向后的引用

HashMap为什么是线程不安全的

JDK1.7：死循环、数据丢失
JDK1.8：数据覆盖。插入之前时间片耗尽，另一个插入，则可能造成数据覆盖。

JDK1.7 中，由于多线程对HashMap进行扩容，调用了HashMap#transfer()，具体原因：某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。
JDK1.8 中，由于多线程对HashMap进行put操作，调用了HashMap#putVal()，具体原因：假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

/*
扩容操作，重新定位每个桶的下标，并采用头插法将元素迁移到新数组中。
头插法会将链表的顺序翻转，这也是形成死循环的关键点.
*/
void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length;
    for (Entry<K,V> e : table) {
        while(null != e) {
            Entry<K,V> next = e.next;
            if (rehash) {
                e.hash = null == e.key ? 0 : hash(e.key);
            }
            int i = indexFor(e.hash, newCapacity);
            e.next = newTable[i];
            newTable[i] = e;
            e = next;
        }
    }
}

名词解释

哈希冲突：当key的hash值对数组大小取模后，如果值相同，那么就是哈希冲突，会形成一条entry链

加载因子：为了减少哈希冲突，官方设定了一个值为0.75，当键值对达到总容量的75%时，则进行扩容。可以空间换时间，将加载因子手动调低

如何保证是2的幂次方

tableSizeFor方法，可以保证返回的值为大于=n的2的幂次方的数

static final int tableSizeFor(int cap) {
    int n = cap - 1;
    n |= n >>> 1;
    n |= n >>> 2;
    n |= n >>> 4;
    n |= n >>> 8;
    n |= n >>> 16;
    return (n < 0) ? 1 : (n >= 1 << 30) ? 1 << 30 : n + 1;
}

为什么扩容是2倍，不是3倍？或者为什么要保证是2的幂次方？

• 减少元素位置的移动
• 使元素分配更加均匀，减少哈希碰撞

HashMap的put过程

首先计算key的hash值，hash = key.hashCode() ^ key.hashCode() >>> 16，高位补0。

计算下标为index = (table.length - 1) & hash

相关源码

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

//实现Map.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;
    // 步骤①：tab为空则创建 
    // table未初始化或者长度为0，进行扩容
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    // 步骤②：计算index，并对null做处理  
    // (n - 1) & hash 确定元素存放在哪个桶中，桶为空，新生成结点放入桶中(此时，这个结点是放在数组中)
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
    // 桶中已经存在元素
    else {
        Node<K,V> e; K k;
        // 步骤③：节点key存在，直接覆盖value 
        // 比较桶中第一个元素(数组中的结点)的hash值相等，key相等
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
                // 将第一个元素赋值给e，用e来记录
                e = p;
        // 步骤④：判断该链为红黑树 
        // hash值不相等，即key不相等；为红黑树结点
        // 如果当前元素类型为TreeNode，表示为红黑树，putTreeVal返回待存放的node, e可能为null
        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) {
                    // 在尾部插入新结点
                    p.next = newNode(hash, key, value, null);
                    //判断链表的长度是否达到转化红黑树的临界值，临界值为8
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        //链表结构转树形结构
                        treeifyBin(tab, hash);
                    // 跳出循环
                    break;
                }
                // 判断链表中结点的key值与插入的元素的key值是否相等
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    // 相等，跳出循环
                    break;
                // 用于遍历桶中的链表，与前面的e = p.next组合，可以遍历链表
                p = e;
            }
        }
        //判断当前的key已经存在的情况下，再来一个相同的hash值、key值时，返回新来的value这个值
        if (e != null) { 
            // 记录e的value
            V oldValue = e.value;
            // onlyIfAbsent为false或者旧值为null
            if (!onlyIfAbsent || oldValue == null)
                //用新值替换旧值
                e.value = value;
            // 访问后回调
            afterNodeAccess(e);
            // 返回旧值
            return oldValue;
        }
    }
    // 结构性修改
    ++modCount;
    // 步骤⑥：超过最大容量就扩容 
    // 实际大小大于阈值则扩容
    if (++size > threshold)
        resize();
    // 插入后回调
    afterNodeInsertion(evict);
    return null;
}

为什么用异或计算hash

得到的值更加均匀

个人观点：补充一些，hashcode为int类型，4个字节32位，为了确保散列性，肯定是32位都能进行散列算法计算是最好的。 首先要明白，为什么用异或计算，二进制位计算，a 只可能为0,1，b只可能为0,1。a中0出现几率为1/2,1也是1/2，b同理。 位运算符有三种，|，&，……，或，与，亦或。 a,b进行位运算，有4种可能 00，01,10,11 a或b计算 结果为1的几率为3/4,0的几率为1/4 a与b计算 结果为0的几率为3/4,1的几率为1/4, a亦或b计算 结果为1的几率为1/2,0的几率为1/2 所以，进行亦或计算，得到的结果肯定更为平均，不会偏向0或者偏向1，更为散列。 右移16位进行亦或计算，我将其拆分为两部分，前16位的亦或运算，和后16位的亦或运算， 后16位的亦或运算，即原hashcode后16位与原hashcode前16位进行亦或计算，得出的结果，前16位和后16位都有参与其中，保证了 32位全部进行计算。 前16位的亦或运算，即原hasecode前16位与0000 0000 0000 0000进行亦或计算，结果只与前16位hashcode有关，同时亦或计算，保证 结果为0的几率为1/2,1的几率为1/2，也是平均的。 所以为什么是右移16位，个人觉得博主说的原因是一部分， 也有一个原因是右移16位进行亦或计算的结果中， （1）结果的后16位保证了hashcode32位全部参与计算，也保证了0,1平均，散列性 （2）结果的前16位保证hashcode前16位了0，1平均散列性，附带hashcode前16位参与计算。 (3) 16与16位数相同，利于计算，不需要补齐，移去位数数据 更多情况，hashmap只会用到前16位（临时数据一般不会这么大），所以（1）占主因

如何散列

直接进行hash取余操作，可能导致散列不均匀的情况（参与运算的只有hashcode的低位），最坏情况会形成一个单链表。所以对hashCode做了一定的优化，让高位也参与运算，使其更加平均，减少哈希碰撞，这样的操作叫做扰动

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);// 与自己右移16位进行异或运算（高低位异或）
}

这比在JDK 1.7中，更为简洁，相比在1.7中的4次位运算，5次异或运算（9次扰动），在1.8中，只进行了1次位运算和1次异或运算（2次扰动）；

如何解决hash冲突

1.8之前，如果有冲突将值加入链表中，又叫拉链法

1.8之后，链表长度大于8，调用treeifyBin方法，会判断hashmap数组长度是否大于等于64，如果是则转为红黑树，以减少搜索时间，否则执行resize方法扩容

扩容条件是什么

大于容量*扩容因子（默认0.75f），loadFactor 越大数组越密，越少越稀疏。0.75是官方给出的一个比较好的临界值。threshold = capacity \* loadFactor，用来衡量是否需要扩容

扩容怎么实现的

1. 在jdk1.8中，添加元素个数大于阀值时或者初始化时，就调用resize方法进行扩容；
2. 每次扩展的时候，新容量为旧容量的2倍；
3. 扩展后元素的位置要么在原位置，要么移动到原位置 + 旧容量的位置；

在putVal()中使用到了2次resize()方法，resize()方法在进行第一次初始化时会对其进行扩容，或者当该数组的实际大小大于其临界值(第一次为12)，这个时候在扩容的同时也会伴随的桶上面的元素进行重新分发，这也是JDK1.8版本的一个优化的地方，在1.7中，扩容之后需要重新去计算其Hash值，根据Hash值对其进行分发，但在1.8版本中，则是根据在同一个桶的位置中进行判断(e.hash & oldCap)是否为0，重新进行hash分配后，该元素的位置要么停留在原始位置，要么移动到原始位置+旧容量的位置

resize源码解读

final Node<K,V>[] resize() {
    Node<K,V>[] oldTab = table;//oldTab指向hash桶数组
    int oldCap = (oldTab == null) ? 0 : oldTab.length;
    int oldThr = threshold;
    int newCap, newThr = 0;
    if (oldCap > 0) {//如果oldCap不为空的话，就是hash桶数组不为空
        if (oldCap >= MAXIMUM_CAPACITY) {//如果大于最大容量了，就赋值为整数最大的阀值
            threshold = Integer.MAX_VALUE;
            return oldTab;//返回
        }//如果当前hash桶数组的长度在扩容后仍然小于最大容量 并且oldCap大于默认值16
        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                 oldCap >= DEFAULT_INITIAL_CAPACITY)
            newThr = oldThr << 1; // double threshold 双倍扩容阀值threshold
    }
    // 旧的容量为0，但threshold大于零，代表有参构造有cap传入，threshold已经被初始化成最小2的n次幂
    // 直接将该值赋给新的容量
    else if (oldThr > 0) // initial capacity was placed in threshold
        newCap = oldThr;
    // 无参构造创建的map，给出默认容量和threshold 16, 16*0.75
    else {               // zero initial threshold signifies using defaults
        newCap = DEFAULT_INITIAL_CAPACITY;
        newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
    }
    // 新的threshold = 新的cap * 0.75
    if (newThr == 0) {
        float ft = (float)newCap * loadFactor;
        newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                  (int)ft : Integer.MAX_VALUE);
    }
    threshold = newThr;
    // 计算出新的数组长度后赋给当前成员变量table
    @SuppressWarnings({"rawtypes","unchecked"})
        Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];//新建hash桶数组
    table = newTab;//将新数组的值复制给旧的hash桶数组
    // 如果原先的数组没有初始化，那么resize的初始化工作到此结束，否则进入扩容元素重排逻辑，使其均匀的分散
    if (oldTab != null) {
        // 遍历新数组的所有桶下标
        for (int j = 0; j < oldCap; ++j) {
            Node<K,V> e;
            if ((e = oldTab[j]) != null) {
                // 旧数组的桶下标赋给临时变量e，并且解除旧数组中的引用，否则就数组无法被GC回收
                oldTab[j] = null;
                // 如果e.next==null，代表桶中就一个元素，不存在链表或者红黑树
                if (e.next == null)
                    // 用同样的hash映射算法把该元素加入新的数组
                    newTab[e.hash & (newCap - 1)] = e;
                // 如果e是TreeNode并且e.next!=null，那么处理树中元素的重排
                else if (e instanceof TreeNode)
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                // e是链表的头并且e.next!=null，那么处理链表中元素重排
                else { // preserve order
                    // loHead,loTail 代表扩容后不用变换下标，见注1
                    Node<K,V> loHead = null, loTail = null;
                    // hiHead,hiTail 代表扩容后变换下标，见注1
                    Node<K,V> hiHead = null, hiTail = null;
                    Node<K,V> next;
                    // 遍历链表
                    do {             
                        next = e.next;
                        if ((e.hash & oldCap) == 0) {
                            if (loTail == null)
                                // 初始化head指向链表当前元素e，e不一定是链表的第一个元素，初始化后loHead
                                // 代表下标保持不变的链表的头元素
                                loHead = e;
                            else                                
                                // loTail.next指向当前e
                                loTail.next = e;
                            // loTail指向当前的元素e
                            // 初始化后，loTail和loHead指向相同的内存，所以当loTail.next指向下一个元素时，
                            // 底层数组中的元素的next引用也相应发生变化，造成lowHead.next.next.....
                            // 跟随loTail同步，使得lowHead可以链接到所有属于该链表的元素。
                            loTail = e;                           
                        }
                        else {
                            if (hiTail == null)
                                // 初始化head指向链表当前元素e, 初始化后hiHead代表下标更改的链表头元素
                                hiHead = e;
                            else
                                hiTail.next = e;
                            hiTail = e;
                        }
                    } while ((e = next) != null);
                    // 遍历结束, 将tail指向null，并把链表头放入新数组的相应下标，形成新的映射。
                    if (loTail != null) {
                        loTail.next = null;
                        newTab[j] = loHead;
                    }
                    if (hiTail != null) {
                        hiTail.next = null;
                        newTab[j + oldCap] = hiHead;
                    }
                }
            }
        }
    }
    return newTab;
}

HashSet如何检查重复元素？如何保证数据是不可重复的？

add()添加时，不仅比较hash值，还会使用equlas比较，HashSet的add()会调用HashMap的put()

底层就是利用HashMap实现的，在添加相同的key时会覆盖原有的value值，返回原有的value值，所以不会重复

部分源码

private static final Object PRESENT = new Object();
private transient HashMap<E,Object> map;

public HashSet() {
    map = new HashMap<>();
}

public boolean add(E e) {
    // 调用HashMap的put方法,PRESENT是一个至始至终都相同的虚值
	return map.put(e, PRESENT)==null;
}

谈谈ConcurrentHashMap

1.7底层使用segment数组 + hashmap数组 + 链表

Java7 中 ConcurrentHashMap 使用的分段锁，初始化之后不可以扩容，默认值为16，也就是ConcurrentHashMap中有16个segment，理论上支持16个线程并发写，进行扩容时，实际是segment数组中的HashEntry进行扩容，为原来的2倍，这个时候不需要考虑并发，因为segment是持有独占锁的。

1.8与hashmap一样，node数组 + 链表 / 红黑树

Java8 中的 ConcurrentHashMap 使用的 Synchronized 锁加 CAS 的机制。结构也由 Java7 中的 Segment 数组 + HashEntry 数组 + 链表 进化成了 Node 数组 + 链表 / 红黑树，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时会转化成红黑树，在冲突小于一定数量时又退回链表。

JDK1.8 中为什么使用内置锁 synchronized替换 可重入锁 ReentrantLock？

1. 首先在1.6中，synchronized实现了大量优化，会从无锁->偏向锁->轻量级锁->重量级锁
2. 并不是每个节点都需要同步支持的，只有头结点需要，使用lock基于AQS每个节点都会继承来获得同步支持，无疑带来了巨大的内存浪费

谈谈NIO

从1.4开始有的，目的是为了提高速度。可以翻译为new-io或者non-blocking-io

与传统IO的区别
传统io是一个一个字节处理的，nio是以块处理的，还是非阻塞的，传统io是阻塞的
nio有三个核心部分：选择器（selector）- 用于检查多个channel的变更情况
管道（channel），缓冲区（buffer）

谈谈反射

可以在类运行时获取类的信息，运行时解释：java文件编译后会变为class文件，而class文件会被jvm装载运行。

为什么匿名内部类要用final常量

生命周期不一致，局部变量存于栈中，当方法执行结束后，非final被销毁，而局部内部类的引用还存在，此时内部类在调用的时候就会出错，加了final约束了对象的强一致性，避免了此问题

谈谈BIO,NIO,AIO的区别

简答

• BIO：Block IO 同步阻塞式 IO，就是我们平常使用的传统 IO，它的特点是模式简单使用方便，并发处理能力低。
• NIO：Non IO 同步非阻塞 IO，是传统 IO 的升级，客户端和服务器端通过 Channel（通道）通讯，实现了多路复用。
• AIO：Asynchronous IO 是 NIO 的升级，也叫 NIO2，实现了异步非堵塞IO ，异步 IO 的操作基于事件和回调机制。

详细回答：BIO (Blocking I/O): 同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。在活动连接数不是特别高（小于单机1000）的情况下，这种模型是比较不错的，可以让每一个连接专注于自己的 I/O 并且编程模型简单，也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。但是，当面对十万甚至百万级连接的时候，传统的 BIO 模型是无能为力的。因此，我们需要一种更高效的 I/O 处理模型来应对更高的并发量。
NIO (Non I/O): NIO是一种同步非阻塞的I/O模型，在Java 1.4 中引入了NIO框架，对应 java.nio 包，提供了 Channel , Selector，Buffer等抽象。NIO中的N可以理解为Non-blocking，不单纯是New。它支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发
AIO (Asynchronous I/O): AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。查阅网上相关资料，我发现就目前来说 AIO 的应用还不是很广泛，Netty 之前也尝试使用过 AIO，不过又放弃了。

Java内存模型（其实涉及到并发编程）

是什么
Java内存模型（java memory model）是一种抽象概念，约定或规范，关键技术点是围绕多线程的原子性，可见性与有序性展开的
为什么会出现
屏蔽掉各种硬件和操作系统的内存访问差异
解决了什么

• 让Java程序在各个平台下都能达到一致的内存访问效果
• JMM规范了JVM与计算机内存是如何协同工作的
• 规定了一个线程如何看到共享变量的值，以及如何同步的访问共享变量

三大特性
可见性：一个线程修改了某一个共享变量的值，其他线程能够立即知道该变更。JMM规定所有变量都存于主内存中

有序性：程序只保证结果相等，编译器和处理器为了提升性能会对指定序列进行重排序。但只保证串行语义一致，没有义务保证多线程语义也一致（可能产生脏读）
原子性：一次或多次操作，要么全部执行，要么都不执行

JMM内存模型从1.5重新修订，1.8仍然在使用

扩展

更多内容可点击参照这篇文章

集合相关文章

谈谈你对JMM的理解

JMM希望屏蔽各种硬件和操作系统的访问差异，保证Java在各种平台下对内存访问都能达到一致的效果

解决多线程存在的原子性，可见性，和有序性的问题，JMM主要内容有以下几块

• JMM的抽象结构。线程的所有操作必须于本地内存（私有的），不能操作主内存
  
  JMM的操作指令及其作用，从上而下有used，load，store，read，write，lock，unlock
  
• happen-before原则。阐述可见性，有了这个原则我们的代码才不会发生重排序
• volatile。解决可见性和重排。实现依据是内存屏障

谈谈Object object = new Object()

引用在方法区，变量在栈，对象在堆中
占多少内存？在64位系统中16个字节，只有一个对象头占内存，mark word占了8字节，类型指针（classpoint）占了8个字节

• 启动了压缩指针 -XX:UseCompressedClassPointers 就是4个byte

new一个对象要经历哪些过程？

1. 加载初始化类。查看对象所属的类是否加载到内存中，如果没有则通过对象所属的class文件加载到内存中
2. 创建对象化。初始化完成后，在进行对象的创建工作

加载初始化类
类加载器收到请求，会将请求委托给父类（以此类推）只有当父类无法加载，子加载器才会尝试加载（可以保证全局唯一性）
该模型称为双亲委派模型

1. 加载
2. 验证（语义，操作）
3. 准备（为静态变量分配空间）
4. 解析
5. 初始化（先父后子，静态变量赋值，执行static代码块）

创建对象

1. 在堆中分配对象所需要的内存
2. 对所有成员变量赋初值（方法区copy到堆赋值）
3. 执行实例化代码

什么是双亲委派机制？它的工作流程是什么样的？模型的好处是什么？

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在JVM中的唯一性，每一个类加载器，都有一个独立的类名称空间。类加载器就是根据指定全限定名称将class文件加载到JVM 内存，然后再转化为 class 对象。

双亲委派模型：如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去加载，每一层的类加载器都是如此，这样所有的加载请求都会被传送到顶层的启动类加载器中，只有当父加载器无法完成加载请求（它的搜索范围中没找到所需的类）时，子加载器才会尝试去加载此类。

自下而上检查类是否已经被加载，自上而下尝试加载类

双亲委派模型工作流程：

1. 当Application ClassLoader 收到一个类加载请求时，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器Extension ClassLoader去完成。

2. 当Extension ClassLoader收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父类加载器Bootstrap ClassLoader去完成。

3. Bootstrap ClassLoader尝试加载此类，如果Bootstrap ClassLoader加载失败，就会让Extension ClassLoader尝试加载。

4. Extension ClassLoader尝试加载此类，如果Extension ClassLoader也加载失败，就会让Application ClassLoader尝试加载。

5. Application ClassLoader尝试加载此类，如果Application ClassLoader也加载失败，就会让自定义加载器尝试加载。

6. 如果均加载失败，就会抛出ClassNotFoundException异常。

双亲委派模型的好处：保证核心类库不被覆盖。如果没有使用双亲委派模型，由各个类加载器自行加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不同的Object类， Java类型体系中最基础的行为就无法保证，应用程序也将会变得一片混乱。

谈谈动态代理

动态代理有常见的两种实现方式，jdk代理和cglib代理
jdk利用了反射的机制
cglib利用的是asm框架，通过修改字节码生成子类来处理