面向Java面试

1.6源码

1.8源码

总体结构上与 HashMap 类似，也是“数组 - 链表”的结构，但同步的粒度要更细致一些。

内部仍有 Segment，但只是保证序列化时的兼容性，已不具作用。由于不再使用 Segment，初始化操作简化为 lazy-load 形式；
数据存储利用 volatile 保证可见性；
使用 CAS 操作，在特定场景下进行无锁并发操作（高并发场景下性能一般）；
使用 Unsafe、LongAdder 之类底层手段，进行极端情况的优化。
存储节点：key 定义为 final，val、next 都定义为 volatile 保证可见性。

static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;
// …
}

对于 put 操作：
final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException();
int hash = spread(key.hashCode());
int binCount = 0;
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh; K fk; V fv;
if (tab == null || (n = tab.length) == 0)
tab = initTable();
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
// 利用 CAS 去进行无锁线程安全操作，如果 bin 是空的
if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value)))
break;
}
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else if (onlyIfAbsent // 不加锁，进行检查
&& fh == hash
&& ((fk = f.key) == key || (fk != null && key.equals(fk)))
&& (fv = f.val) != null)
return fv;
else {
V oldVal = null;
synchronized (f) {
// 细粒度的同步修改操作...
}
}
// Bin 超过阈值，进行树化
if (binCount != 0) {
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
addCount(1L, binCount);
return null;
}
对于初始化操作：
在一个 initTable 实现，利用 volatile 的 sizeCtl 作为互斥手段，
如果发生竞争性的初始化，就 spin （自旋锁）在哪里，等待条件回复；
否则利用 CAS 设置排他标志。如果成功则进行初始化，否则重试；
当 bin 为空时，同样是没有必要锁定，而以 CAS 操作放置；
同步逻辑上使用 synchronized（性能已被优化，且可以减少内存消耗）；
更多细节实现通过 Unsafe 进行优化，如 tabAt 利用 getObjectAcquire 避免间接调用的开销。
private final Node<K,V>[] initTable() {
Node<K,V>[] tab; int sc;
while ((tab = table) == null || tab.length == 0) {
// 如果发现冲突，进行 spin 等待
if ((sc = sizeCtl) < 0)
Thread.yield();
// CAS 成功返回 true，则进入真正的初始化逻辑
else if (U.compareAndSetInt(this, SIZECTL, sc, -1)) {
try {
if ((tab = table) == null || tab.length == 0) {
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = tab = nt;
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
对于 size 操作：
也是采用分治的方法进行计数，然后做求和处理：
求和处理是通过 CounterCell 实现，而 CounterCell 操作，是基于 LongAdder 进行的（略）。
final long sumCount() {
CounterCell[] as = counterCells; CounterCell a;
long sum = baseCount;
if (as != null) {
for (int i = 0; i < as.length; ++i) {
if ((a = as[i]) != null)
sum += a.value;
}
}
return sum;
}

static final class CounterCell {
volatile long value;
CounterCell(long x) { value = x; }
}

分段锁，在数据结构内部进行分段（Segment，默认16个），
内部使用 HashEntry 的数组，与 HashMap 类似，哈希值相同的值使用链表存放；

HashEntry 内部使用 volatile 修饰的值保证可见性，
也利用不可变对象的机制改进利用 Unsafe 提供的底层能力。
对于 get 操作，保证的是可见性，所以没有同步的逻辑。
public V get(Object key) {
Segment<K,V> s; // manually integrate access methods to reduce overhead
HashEntry<K,V>[] tab;
int h = hash(key.hashCode());
// 利用位操作替换普通数学运算
long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
// 以 Segment 为单位，进行定位
// 利用 Unsafe 直接进行 volatile access
if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
(tab = s.table) != null) {
// 省略
}
return null;
}

对于 put 操作，首先通过二次哈希避免冲突，
再以 Unsafe 调用方式直接获取的 Segment，进行线程安全的 put 操作：

获取重入锁：要确保数据一致性（Segment 本身是基于 ReentrantLock 的扩展实现），
在并发修改期间，相应的 Segment 是被锁定的；
重复性扫描：确定 Key 值是否已经存在于数组，进而决定执行更新或插入操作；
扩容：和 HashMap 类似，可能发生扩容问题，但也是针对 Segment 进行扩容。
final V put(K key, int hash, V value, boolean onlyIfAbsent) {
// scanAndLockForPut 会去查找是否有 key 相同 Node
// 无论如何，确保获取锁
HashEntry<K,V> node = tryLock() ? null :
scanAndLockForPut(key, hash, value);
V oldValue;
try {
HashEntry<K,V>[] tab = table;
int index = (tab.length - 1) & hash;
HashEntry<K,V> first = entryAt(tab, index);
for (HashEntry<K,V> e = first;;) {
if (e != null) {
K k;
// 更新已有 value...
}
else {
// 放置 HashEntry 到特定位置，如果超过阈值，进行 rehash
// ...
}
} finally {
unlock();
}
return oldValue;
}

对于 size 操作，则涉及分离锁的副作用，ConcurrentHashMap 则采用重试机制，
如没有监控到变化（modCount）则直接返回，
否则再获取锁（初始化操作也要锁定所有 Segment）。

1. <? extends T>表示该通配符所代表的类型是T类型的子类。
2. <? super T>表示该通配符所代表的类型是T类型的父类

静态（static）方法调用

普通方法调用

私有方法调用

不需要显示的在程序中进行try...catch处理

如：
NullPointerException、
ConcurrentModificationException、
IndexOutOfBoundsException、
ClassCastException、
NoSuchElementException

必须在程序中显示进行异常捕获处理

如：IOException、SQLException、FileNotFoundException等

使用 TCP 协议实现网络通信。

ServerSocket：服务器端类
Socket：客户端类
服务器和客户端通过 InputStream 和 OutputStream 进行输入输出。

一个简单的 Socket 服务器实现：

public class DemoServer extends Thread {
private ServerSocket serverSocket;
public int getPort() {
return serverSocket.getLocalPort();
}

public void run() {
try {
// 服务端启动 ServerSocket，自动绑定一个空闲端口
serverSocket = new ServerSocket(0);
while (true) {
// 调用 accept 方法，阻塞等待客户端连接
Socket socket = serverSocket.accept();
RequestHandler requestHandler = new RequestHandler(socket);
requestHandler.start();
}
} catch (IOException e) {
e.printStackTrace();
} finally {
if (serverSocket != null) {
try {
serverSocket.close();
} catch (IOException e) {
e.printStackTrace();
};
}
}
}

public static void main(String[] args) throws IOException {
DemoServer server = new DemoServer();
server.start();
// 利用 Socket 模拟一个客户端，只进行连接、读取和打印
try (Socket client = new Socket(InetAddress.getLocalHost(), server.getPort())) {
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(client.getInputStream()));
bufferedReader.lines().forEach(s -> System.out.println(s));
}
}
}

// 简化实现，不做读取，直接发送字符串
class RequestHandler extends Thread {
private Socket socket;
RequestHandler(Socket socket) {
this.socket = socket;
}

@Override
public void run() {
try (PrintWriter out = new PrintWriter(socket.getOutputStream());) {
out.println("Hello world!");
out.flush();
} catch (Exception e) {
e.printStackTrace();
}
}
}

创建 Selector，充当类似调度员的角色。

Selector selector = Selector.open();

创建通道必须配置为非阻塞模式，
否则使用选择器就没有任何意义了，
因为如果通道在某个事件上被阻塞，
那么服务器就不能响应其它事件，
必须等待这个事件处理完毕才能去处理其它事件
（而且注册也不允许，会抛出 ILLegalBlockingModeException 异常）。

ServerSocketChannel ssChannel = ServerSocketChannel.open();
ssChannel.configureBlocking(false);
ssChannel.register(selector, SelectionKey.OP_ACCEPT); // 请求接入
在将通道注册到选择器上时，还需要指定要注册的具体事件，主要有以下几类：

SelectionKey.OP_CONNECT
SelectionKey.OP_ACCEPT
SelectionKey.OP_READ
SelectionKey.OP_WRITE

它们在 SelectionKey 的定义如下：

public static final int OP_READ = 1 << 0;
public static final int OP_WRITE = 1 << 2;
public static final int OP_CONNECT = 1 << 3;
public static final int OP_ACCEPT = 1 << 4;



// 可以看出每个事件可以被当成一个位域，从而组成事件集整数，例如：
// int interestSet = SelectionKey.OP_READ | SelectionKey.OP_WRITE;

使用 select() 来监听到达的事件，它会一直阻塞直到有至少一个事件到达。

int num = selector.select();

Set<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> keyIterator = keys.iterator();
while (keyIterator.hasNext()) {
SelectionKey key = keyIterator.next();
if (key.isAcceptable()) {
// ...
} else if (key.isReadable()) {
// ...
}
keyIterator.remove();
}

因为一次 select() 调用不能处理完所有的事件，
并且服务器端有可能需要一直监听事件，
因此服务器端处理事件的代码一般会放在一个死循环内。

while (true) {
int num = selector.select();
Set<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> keyIterator = keys.iterator();
while (keyIterator.hasNext()) {
SelectionKey key = keyIterator.next();
if (key.isAcceptable()) {
// ...
} else if (key.isReadable()) {
// ...
}
keyIterator.remove();
}
}

采用单线程轮询事件的机制，通过高效地定位就绪 Channel 来决定工作，
只有在 select 阶段是阻塞的（等待至少一个客户端请求接入），
可避免大量客户端连接时频繁线程切换的问题。



public class NIOServer {
public static void main(String[] args) throws IOException {
Selector selector = Selector.open();
ServerSocketChannel ssChannel = ServerSocketChannel.open();
ssChannel.configureBlocking(false);
ssChannel.register(selector, SelectionKey.OP_ACCEPT);
ServerSocket serverSocket = ssChannel.socket();
InetSocketAddress address = new InetSocketAddress("127.0.0.1", 8888);
serverSocket.bind(address);
while (true) {
selector.select();
Set<SelectionKey> keys = selector.selectedKeys();
Iterator<SelectionKey> keyIterator = keys.iterator();
while (keyIterator.hasNext()) {
SelectionKey key = keyIterator.next();
if (key.isAcceptable()) {
ServerSocketChannel ssChannel1 = (ServerSocketChannel) key.channel();
// 服务器会为每个新连接创建一个 SocketChannel
SocketChannel sChannel = ssChannel1.accept();
sChannel.configureBlocking(false);
// 这个新连接主要用于从客户端读取数据
sChannel.register(selector, SelectionKey.OP_READ);
} else if (key.isReadable()) {
SocketChannel sChannel = (SocketChannel) key.channel();
System.out.println(readDataFromSocketChannel(sChannel));
sChannel.close();
}
keyIterator.remove();
}
}
}

private static String readDataFromSocketChannel(SocketChannel sChannel) throws IOException {
ByteBuffer buffer = ByteBuffer.allocate(1024);
StringBuilder data = new StringBuilder();
while (true) {
buffer.clear();
int n = sChannel.read(buffer);
if (n == -1) {
break;
}
buffer.flip();
int limit = buffer.limit();
char[] dst = new char[limit];
for (int i = 0; i < limit; i++) {
dst[i] = (char) buffer.get(i);
}
data.append(dst);
buffer.clear();
}
return data.toString();
}
}

public class NIOClient {
public static void main(String[] args) throws IOException {
Socket socket = new Socket("127.0.0.1", 8888);
OutputStream out = socket.getOutputStream();
String s = "hello world";
out.write(s.getBytes());
out.close();
}
}

Supplier<T>

Consumer<T>

Function<T, R>

Predicate<T>

通常作为方法参数来使用（也可作为返回值）：
Stream 的 map 方法接受Function<T, R> 作为参数，
filter 使用Predicate<T>作为参数，
forEach 使用Consumer<T>作为参数。

LocalDate是一个不可变的类，
它表示默认格式(yyyy-MM-dd)的日期，
我们可以使用now()方法得到当前时间，
也可以提供输入年份、月份和日期的输入参数来创建一个LocalDate实例。
该类为now()方法提供了重载方法，我们可以传入ZoneId来获得指定时区的日期。

LocalTime是一个不可变的类
它的实例代表一个符合人类可读格式的时间，
默认格式是hh:mm:ss.zzz。像LocalDate一样，
该类也提供了时区支持，
同时也可以传入小时、分钟和秒等输入参数创建实例

LocalDateTime是一个不可变的日期-时间对象，
它表示一组日期-时间，默认格式是yyyy-MM-dd-HH-mm-ss.zzz。
它提供了一个工厂方法，
接收LocalDate和LocalTime输入参数，
创建LocalDateTime实例。

Instant类是用在机器可读的时间格式上的，
它以Unix时间戳的形式存储日期时间

大多数日期/时间API类都实现了一系列工具方法，
如：加/减天数、周数、月份数，等等。
还有其他的工具方法能够使用TemporalAdjuster调整日期，
并计算两个日期间的周期。

解析和格式化：将一个日期格式转换为不同的格式，
之后再解析一个字符串，得到日期时间对象，这些都是很常见的。

使用Executor来执行任务

原有的Atomic系列类通过CAS来保证并发时操作的原子性，
但是高并发也就意味着CAS的失败次数会增多，
失败次数的增多会引起更多线程的重试，
最后导致AtomicLong的效率降低。

低并发时两个类差不多，而高并发时使用LongAdder更高效

File[] hiddenFiles = new File(".").listFiles(new FileFilter() {
public boolean accept(File file) {
return file.isHidden();
}
});

子主题

File[] hiddenFiles = new File(".").listFiles(File::isHidden);

与用对象引用传递对象类似（对象引用是用new创建的），
在Java 8里写下
File::isHidden的时候，你就创建了一个方法引用，你同样可以传递它

子主题

before Java8

Java8

before Java8

Java8

用集合的话，你得自己去做迭代的过程。
你得用for-each循环一个个去迭代元素，然后再处理元素。
我们把这种数据迭代的方法称为外部迭代。
相反，有了Stream API，你根本用不着操心循环的事情。
数据处理完全是在库内部进行的。
我们把这种思想叫作内部迭代。

顺序处理

并行处理

初始方案

方案二：
把颜色作为参数

子主题

子主题

调用

List greenApples = filterApples(inventory, "green", 0, true); 
List heavyApples = filterApples(inventory, "", 150, false); 

public interface ApplePredicate{
    boolean test (Apple apple);
}

子主题

子主题

找出所有重量超过150克的红苹果

多种行为，一个参数

子主题

子主题

目前，filterApples方法还只适用于Apple。
你还可以将List类型抽象化，从而超越你眼前要处理的问题

// java.util.Comparator
public interface Comparator {
    public int compare(T o1, T o2);
} 

可以随时创建Comparator的实现，
用sort方法表现出不同的行为。

// java.lang.Runnable
public interface Runnable{
    public void run();
}

只定义一个抽象方法的接口

函数式接口的抽象方法的签名基本上就是Lambda表达式的签名。
我们将这种抽象方法叫作函数描述符。

可以直接把一个Lambda传给process方法

子主题

把行为传递给processFile，
以便它可以利用BufferedReader执行不同的行为

Lambda仅可用于上下文是函数式接口的情况。
你需要创建一个能匹配  BufferedReader -> String，
还可以抛出IOException异常的接口。
让我们把这一接口叫作  BufferedReaderProcessor

把这个接口作为新的processFile方法的参数

Lambda表达式允许你直接内联，
为函数式接口的抽象方法提供实现，
并且将整个表达式作为函数式接口的一个实例。

通过传递不同的Lambda重用processFile方法，
并以不同的方式处理文件

子主题

java.util.function.Predicate<T>接口
定义了一个名叫test的抽象方法，
它接受泛型T对象，并返回一个boolean。

在需要表示一个涉及类型T的布尔表达式时，
就可以使用这个接口。

java.util.function.Consumer<T>
定义了一个名叫accept的抽象方法，
它接受泛型T的对象，没有返回（void）。
你如果需要访问类型T的对象，
并对其执行某些操作，就可以使用这个接口。

java.util.function.Function<T>接口
定义了一个叫作apply的方法，
它接受一个泛型T的对象，
并返回一个泛型R的对象

如果你需要定义一个Lambda，
将输入对象的信息映射
到输出，
就可以使用这个接口
（比如提取苹果的重量，或把字符串映射为它的长度）

Lambda的类型是从使用Lambda的上下文推断出来的。

上下文（比如，接受它传递的方法的参数，或接受它的值的局部变量）
中Lambda表达式需要的类型称为目标类型。

解读Lambda表达式的类型检查过程

有了目标类型的概念，
同一个Lambda表达式就可以与不同的函数式接口联系起来，
只要它们的抽象方法签名能够兼容。

前面提到的Callable和PrivilegedAction，
这两个接口都代表着什么也不接受且返回一个泛型T的函数

更多的例子

特殊的void兼容规则

Java编译器会从上下文（目标类型）
推断出用什么函数式接口来配合Lambda表达式，
这意味着它也可以推断出适合Lambda的签名，
因为函数描述符可以通过目标类型来得到。
这样做的好处在于，
编译器可以了解Lambda表达式的参数类型，
这样就可以在Lambda语法中省去标注参数类型

Lambda表达式也允许使用自由变量
（不是参数，而是在外层作用域中定义的变量），
就像匿名类一样。 它们被称作捕获Lambda。

Lambda可以没有限制地捕获（也就是在其主体中引用）实例变量和静态变量。
但局部变量必须显式声明为final，或事实上是final。
换句话说，Lambda表达式只能捕获指派给它们的局部变量一次。
（注：捕获实例变量可以被看作捕获最终局部变量this。）

对局部变量的限制

用方法引用写的一个排序

基本思想是，
如果一个Lambda代表的只是“直接调用这个方法”，
那最好还是用名称来调用它，而不是去描述如何调用它。

方法引用就是让你根据已有的方法实现来创建Lambda表达式。
但是，显式地指明方法的名称，你的代码的可读性会更好。

当你需要使用方法引用时，目标引用放在分隔符::前，方法的名称放在后面

如何构建方法引用

还有针对构造函数、数组构造函数
和父类调用（super-call）的一些特殊形式的方法引用。

对于一个现有构造函数，
你可以利用它的名称和关键字new来创建它的一个引用：
ClassName::new。它的功能与指向静态方法的引用类似。

不将构造函数实例化却能够引用它

怎样才能对具有三个参数的构造函数，
比如Color(int, int, int)，使用构造函数引用呢？

最终解决方案是这样的:

inventory.sort(comparing(Apple::getWeight));

Java 8的API已经为你提供了一个List可用的sort方法，
sort方法的签名是这样的:
void sort(Comparator c)

inventory.sort(new Comparator() {
    public int compare(Apple a1, Apple a2){
        return a1.getWeight().compareTo(a2.getWeight());
    }
});

Lambda表达式提供了一种轻量级语法来实现相同的目标：传递代码。
在需要函数式接口的地方可以使用Lambda表达式。
我们回顾一下：函数式接口就是仅仅定义一个抽象方法的接口。
抽象方法的签名（称为函数描述符）描述了Lambda表达式的签名。

方法引用就是替代那些转发参数的Lambda表达式的语法糖。
可以用方法引用让代码更简洁（假设静态导入了java.util.Comparator.comparing）

函数式接口中怎么可能有更多的方法呢？
（毕竟，这违背了函数式接口的定义啊！）
窍门在于，即将介绍的方法都是默认方法，
也就是说它们不是抽象方法。

以使用静态方法Comparator.comparing，
根据提取用于比较的键值的Function来返回一个Comparator，
如下所示：
Comparator<Apple> c = Comparator.comparing(Apple::getWeight);

1. 逆序

2. 比较器链

谓词接口包括三个方法：negate、and和or，
可以重用已有的Predicate来创建更复杂的谓词。

请注意，and和or方法是按照在表达式链中的位置，
从左向右确定优先级的。因此，a.or(b).and(c)可以看作(a || b) && c

可以把Function接口所代表的Lambda表达式复合起来

Function接口为此配了andThen和compose两个默认方法，
它们都会返回Function的一个实例

andThen和compose之间的区别

Java7

Java8

像集合一样，流也提供了一个接口，
可以访问特定元素类型的一组有序值。

流会使用一个提供数据的源，如集合、数组或输入/输出资源。
请注意，从有序集合生成流时会保留原有的顺序。
由列表生成的流，其元素顺序与列表一致

—流的数据处理功能支持类似于数据库的操作，
以及函数式编程语言中的常用操作，
如filter、map、reduce、find、match、sort等。
流操作可以顺序执行，也可并行执行。

很多流操作本身会返回一个流，这样多个操作就可以链接起来，形成一个大的流水线。

流水线的操作可以看作对数据源进行数据库式查询。

与使用迭代器显式迭代的集合不同，流的迭代操作是在背后进行的。

子主题

集合则是急切创建的（供应商驱动：先把仓库装满，再开始卖，就像那些昙花一现的圣诞新玩意儿一样）。

流就像是一个延迟创建的集合：
只有在消费者要求的时候才会计算值
（用管理学的话说这就是需求驱动，甚至是实时制造)

会抛出一个异常，说流已被消费掉了

使用Collection接口需要用户去做迭代（比如用for-each），这称为外部迭代。
相反，Streams库使用内部迭代——它帮你把迭代做了，
还把得到的流值存在了某个地方，
你只要给出一个函数说要干什么就可以了。

子主题

可以连接起来的流操作

关闭流的操作

流的使用一般包括三件事

Streams接口支持filter方法。
接受一个谓词（一个返回boolean的函数）作为参数，
并返回一个包括所有符合谓词的元素的流。

distinct的方法，返回一个元素各异
（根据流所生成元素的hashCode和equals方法实现）的流

limit(n)方法，会返回一个不超过给定长度的流。
所需的长度作为参数传递给limit。
如果流是有序的，则最多会返回前n个元素。

请注意limit也可以用在无序流上，比如源是一个Set。
这种情况下，limit的结果不会以任何顺序排列。

skip(n)方法，返回一个扔掉了前n个元素的流。
如果流中元素不足n个，则返回一个空流。

请注意，limit(n)和skip(n)是互补的！

List dishes =
                     menu.stream()
                     .filter(d -> d.getType() == Dish.Type.MEAT)
                     .limit(2)
                     .collect(toList()); 

map方法，接受一个函数作为参数。
这个函数会被应用到每个元素上，
并将其映射成一个新的元素
（使用映射一词，是因为它和转换类似，
但其中的细微差别在于它是“创建一个新版本”而不是去“修改”）。

flatmap方法让你把一个流中的每个值都换成另一个流，然后把所有的流连接
起来成为一个流

用map方法的Lambda，接受一个数字，
并返回该数字平方的Lambda来解决这个问题。

使用两个map来迭代这两个列表，并生成数对。
但这样会返回一个Stream->。
你需要让生成的流扁平化，以得到一个Stream。
这正是flatMap所做的

filter可以配合谓词使用来筛选流中的元素。
因为在flatMap操作后，你有了一个代表数对的int[]流，
所以只需要一个谓词来检查总和是否能被3整除就可以了

检查谓词是否至少匹配一个元素

检查谓词是否匹配所有元素

流中没有任何元素与给定的谓词匹配

短路求值

查找元素

Optional简介

查找第一个元素

元素求和

Lambda反复结合每个元素，直到流被归约成一个值

使用方法引用让这段代码更简洁

reduce还有一个重载的变体，它不接受初始值，但是会返回一个Optional对象

利用reduce来计算流中最大或最小的元素。
reduce接受两个参数：
 一个初始值
 一个Lambda来把两个流元素结合起来并产生一个新值

Lambda是一步步用加法运算符应用到流中每个元素上的，
需要给定两个元素能够返回最大值的Lambda，
reduce操作会考虑新值和流中下一个元素，
并产生一个新的最大值，直到整个流消耗完

计算最小值，你需要把Integer.min传给reduce来替换Integer.max

用map和reduce方法数一数流中有多少个菜呢

内置count方法可用来计算流中元素的个数

Traders

Transactions

子主题

找出2011年的所有交易并按交易额排序（从低到高）

交易员都在哪些不同的城市工作过

查找所有来自于剑桥的交易员，并按姓名排序

返回所有交易员的姓名字符串，按字母顺序排序

有没有交易员是在米兰工作的

打印生活在剑桥的交易员的所有交易额

所有交易中，最高的交易额是多少

找到交易额最小的交易

引入三个原始类型特化流接口来解决这个问题：
IntStream、DoubleStream和LongStream，
分别将流中的元素特化为int、long和double，
从而避免了暗含的装箱成本

和数字打交道时，有一个常用的东西就是数值范围。

两个可以用于IntStream和LongStream的静态方法，
帮助生成这种范围：
range和rangeClosed。
这两个方法都是第一个参数接受起始值，
第二个参数接受结束值。
但range是不包含结束值的，而rangeClosed则包含结束值。

使用静态方法Stream.of，通过显式值创建一个流

子主题

使用empty得到一个空流
Stream<String> emptyStream = Stream.empty();

使用静态方法Arrays.stream从数组创建一个流。它接受一个数组作为参数

子主题

java.nio.file.Files中的很多静态方法都会返回一个流。
例如，一个很有用的方法是Files.lines，它会返回一个由指定文件中的各行构成的字符串流

子主题

Stream API提供了两个静态方法来从函数生成流：Stream.iterate和Stream.generate。
这两个操作可以创建所谓的无限流：不像从固定集合创建的流那样有固定大小的流。由iterate
和generate产生的流会用给定的函数按需创建值，因此可以无穷无尽地计算下去！一般来说，
应该使用limit(n)来对这种流加以限制，以避免打印无穷多个值。

可以简洁而灵活地定义collect用来生成结果集合的标准

对流调用
collect方法将对流中的元素触发一个归约操作（由Collector来参数化）

最直接和最常用的收集器是toList静态方法，它会把流中所有的元素收集到一个List中

List<Transaction> transactions = transactionStream.collect(Collectors.toList());

主要提供了三大功能

long howManyDishes = menu.stream().collect(Collectors.counting());

long howManyDishes = menu.stream().count();

Collectors.maxBy和Collectors.minBy，
来计算流中的最大或最小值。
这两个收集器接收一个Comparator参数来比较流中的元素。

Collectors类专门为汇总提供了一个工厂方法：Collectors.summingInt。
它可接受一个把对象映射为求和所需int的函数，并返回一个收集器；
该收集器在传递给普通的collect方法后即执行我们需要的汇总操作

Collectors.averagingInt  计算数值的平均数

得到两个或更多这样的结果，
而且希望只需一次操作就可以完成。
在这种情况下，可以使用summarizingInt工厂方法返回的收集器。

joining工厂方法返回的收集器会
把对流中每一个对象应用toString方法得到的所有字符串连接成一个字符串。

joining在内部使用了StringBuilder来把生成的字符串逐个追加起来

joining工厂方法有一个重载版本可以接受元素之间的分界符

把菜单中的菜按照类型进行分类

把热量不到400卡路里的菜划分为“低热量”（diet），
热量400到700卡路里的菜划为“普通”（normal），
高于700卡路里的划为“高热量”（fat）。

使用一个由双参数版本的Collectors.groupingBy工厂方法创建的收集器，
它除了普通的分类函数之外，还可以接受collector类型的第二个参数。
那么要进行二级分组的话，我们可以把一个内层groupingBy传递给外层groupingBy，
并定义一个为流中项目分类的二级标准

把第二个groupingBy收集器传递给外层收集器来实现多级分组。
但进一步说，传递给第一个groupingBy的第二个收集器可以是任何类型，
而不一定是另一个groupingBy。

普通的单参数groupingBy(f)（其中f是分类函数）
实际上是groupingBy(f, toList())的简便写法

把收集器的结果转换为另一种类型

把菜单按照素食和非素食分开

List<Dish> vegetarianDishes =
                                    menu.stream().filter(Dish::isVegetarian).collect(toList()); 

分区的好处在于保留了分区函数返回true或false的两套流元素列表。

写一个方法，它接受参数int n，并将前n个自然数分为质数和非质数。

子主题

子主题

实现一个ToListCollector<T>类，
将Stream<T>中的所有元素收集到一个List<T>里

1. 建立新的结果容器：supplier方法

2. 将元素添加到结果容器：accumulator方法

3. 对结果容器应用最终转换：finisher方法

这三个方法已经足以对流进行顺序归约，
至少从逻辑上看可以按图进行。
实践中的实现细节可能还要复杂一点，
一方面是因为流的延迟性质，
可能在collect操作之前还需要完成其他中间操作的流水线，
另一方面则是理论上可能要进行并行归约。

4. 合并两个结果容器：combiner方法

有了这第四个方法，就可以对流进行并行归约了

5. characteristics方法

子主题

将数据抽象成一个类，并将对这个数据的操作作为这个类的方法，
这么设计可以很容易做到 同步，只要在方法上加”synchronized“

将Runnable对象作为一个类的内部类，
共享数据作为这个类的成员变量，
每个线程对共享数 据的操作方法也封装在外部类，
以便实现对数据的各个操作的同步和互斥，
作为内部类的各 个Runnable对象调用外部类的这些方法。

当对非 volatile 变量进行读写的时候，
每个线程先从内存拷贝变量到CPU缓存中。
如果计算机有 多个CPU，
每个线程可能在不同的CPU上被处理，
这意味着每个线程可以拷贝到不同的 CPU cache 中。
而声明变量是 volatile 的，
JVM 保证了每次读变量都从内存中读，
跳过 CPU cache 这一步。

 ArrayBlockingQueue（公平、非公平）

用数组实现的有界阻塞队列。
此队列按照先进先出（FIFO）的原则对元素进行排序。
默认情况下 不保证访问者公平的访问队列，
所谓公平访问队列是指阻塞的所有生产者线程或消费者线程，
当 队列可用时，可以按照阻塞的先后顺序访问队列，
即先阻塞的生产者线程，可以先往队列里插入 元素，
先阻塞的消费者线程，可以先从队列里获取元素。
通常情况下为了保证公平性会降低吞吐 量。
我们可以使用以下代码创建一个公平的阻塞队列：

ArrayBlockingQueue fairQueue = new ArrayBlockingQueue(1000,true);

LinkedBlockingQueue（两个独立锁提高并发）

基于链表的阻塞队列，同ArrayListBlockingQueue类似，
此队列按照先进先出（FIFO）的原则对 元素进行排序。
而 LinkedBlockingQueue 之所以能够高效的处理并发数据，
还因为其对于生产者 端和消费者端分别采用了独立的锁来控制数据同步，
这也意味着在高并发的情况下生产者和消费 者可以并行地操作队列中的数据，
以此来提高整个队列的并发性能。


LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE）。 

PriorityBlockingQueue（compareTo排序实现优先）

是一个支持优先级的无界队列。
默认情况下元素采取自然顺序升序排列。
可以自定义实现 compareTo()方法来指定元素进行排序规则，
或者初始化 PriorityBlockingQueue 时，
指定构造 参数Comparator来对元素进行排序。
需要注意的是不能保证同优先级元素的顺序。 

DelayQueue（缓存失效、定时任务 ）

是一个支持延时获取元素的无界阻塞队列。
队列使用PriorityQueue来实现。队列中的元素必须实 现 Delayed 接口，
在创建元素时可以指定多久才能从队列中获取当前元素。
只有在延迟期满时才 能从队列中提取元素。
我们可以将DelayQueue运用在以下应用场景：

1. 缓存系统的设计：可以用 DelayQueue 保存缓存元素的有效期，
    使用一个线程循环查询 DelayQueue，
    一旦能从DelayQueue中获取元素时，表示缓存有效期到了。 
2. 定时任务调度：使用 DelayQueue 保存当天将会执行的任务和执行时间，
    一旦从 DelayQueue 中获取到任务就开始执行，
    从比如 TimerQueue 就是使用 DelayQueue 实现的。 

SynchronousQueue（不存储数据、可用于传递数据）

是一个不存储元素的阻塞队列。
每一个 put 操作必须等待一个 take 操作，
否则不能继续添加元素。
SynchronousQueue 可以看成是一个传球手，
负责把生产者线程处理的数据直接传递给消费者线 程。
队列本身并不存储任何元素，非常适合于传递性场景,
比如在一个线程中使用的数据，传递给 另 外 一 个 线 程 使 用 ，
SynchronousQueue 的 吞 吐 量 高 于 LinkedBlockingQueue 和 ArrayBlockingQueue。

LinkedTransferQueue

是一个由链表结构组成的无界阻塞 TransferQueue 队列。
相对于其他阻塞队列， LinkedTransferQueue多了 tryTransfer和transfer方法。

1. transfer 方法：
    如果当前有消费者正在等待接收元素（消费者使用 take()方法或带时间限制的 poll()方法时），
    transfer 方法可以把生产者传入的元素立刻 transfer（传输）给消费者。
    如果没有消费者在等待接收元素，transfer 方法会将元素存放在队列的 tail 节点，
    并等到该元素 被消费者消费了才返回。

2. tryTransfer 方法。则是用来试探下生产者传入的元素是否能直接传给消费者。
    如果没有消费 者等待接收元素，则返回 false。
    和 transfer 方法的区别是 tryTransfer 方法无论消费者是否 接收，方法立即返回。
    而transfer方法是必须等到消费者消费了才返回。
    对于带有时间限制的tryTransfer(E e, long timeout, TimeUnit unit)方法，
    则是试图把生产者传 入的元素直接传给消费者，
    但是如果没有消费者消费该元素则等待指定的时间再返回，
    如果超时 还没消费元素，则返回false，
    如果在超时时间内消费了元素，则返回true。 

LinkedBlockingDeque

是一个由链表结构组成的双向阻塞队列。
所谓双向队列指的你可以从队列的两端插入和移出元素。
双端队列因为多了一个操作队列的入口，
在多线程同时入队时，也就减少了一半的竞争。
相比其 他的阻塞队列，
LinkedBlockingDeque 多了 addFirst，addLast，offerFirst，offerLast， peekFirst，peekLast 等方法，
以 First 单词结尾的方法，表示插入，获取（peek）或移除双端队 列的第一个元素。
以 Last 单词结尾的方法，表示插入，获取或移除双端队列的最后一个元素。
另 外插入方法add等同于addLast，移除方法remove 等效于removeFirst。
但是take方法却等同 于takeFirst，不知道是不是Jdk的bug，
使用时还是用带有First和Last后缀的方法更清楚。

在初始化 LinkedBlockingDeque 时可以设置容量防止其过渡膨胀。
另外双向阻塞队列可以运用在 “工作窃取”模式中。 

年轻代/新生代（Young Generation）

老年代（Tenured Generation)

注： 1）其中年轻代和年老代位于堆内存，堆内存会从JVM启动参数（如-Xmx:3G表示最大堆内存为3G）指定的内存中分配；

2）Perm Gen不位于堆内存中，而是属于方法区，由虚拟机直接分配，但可以通过-XX:PermSize -XX:MaxPermSize 等参数调整其大小。

简称Perm Gen，位于方法区。用于存放Class、Interface的元数据，
其大小跟项目的规模、类、方法的量有关。
永久代的对象垃圾回收发生在Full GC过程中。

注：Java 8 已经去掉了永久代，用 MetaSpace 予以替代

加载是类加载过程中的一个阶段，
这个阶段会在内存中生成一个代表这个类的java.lang.Class对象，
作为方法区这个类的各种数据的入口。
注意这里不一定非得要从一个Class文件获取，
这里既 可以从ZIP包中读取（比如从jar包和war包中读取），
也可以在运行时计算生成（动态代理），
也可以由其它文件生成（比如将JSP文件转换成对应的Class类）。

为了确保Class文件的字节流中包含的信息是否符合当前虚拟机的要求，并 且不会危害虚拟机自身的安全。

验证魔数 0xCAFEBABE
版本号
元数据验证
字节码是否安全
符号引用验证

准备阶段是正式为静态变量分配内存并设置静态变量的初始值阶段，
即在方法区中分配这些变量所使用的内存空间。
注意这里所说的初始值概念，比如一个类变量定义为：
public static int v = 8080;
实际上变量v在准备阶段过后的初始值为0而不是8080，
将v赋值为8080的  put static       指令是 程序被编译后，
存放于类构造器<client>方法之中。 但是注意如果声明为：
public static final int v = 8080;
在编译阶段会为v生成ConstantValue属性，
在准备阶段虚拟机会根据ConstantValue属性将v 赋值为8080。 

解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。
符号引用就是class文件中 的：
1. CONSTANT_Class_info
2. CONSTANT_Field_info
3. CONSTANT_Method_info
等类型的常量

invokedynamic每次都会重新引用，其他执行会缓存

初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，
除了在加载阶段可以自定义类加载 器以外，
其它操作都由JVM主导。
到了初始阶段，才开始真正执行类中定义的Java程序代码。

类构造器<client>

注意以下几种情况不会执行类初始化：

1. 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
2. 定义对象数组，不会触发该类的初始化。
3. 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触 发定义常量所在的类。
4. 通过类名获取Class对象，不会触发类的初始化。
5. 通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，
    其实这个参数是告诉虚拟机，是否要对类进行初始化。
6. 通过ClassLoader默认的loadClass方法，也不会触发初始化动作

看sun.misc.Launcher,它是一个java虚拟机的入口应用。

public class Launcher {
private static Launcher launcher = new Launcher();
    private static String bootClassPath =
        System.getProperty("sun.boot.class.path");

    public static Launcher getLauncher() {
        return launcher;
    }

    private ClassLoader loader;

    public Launcher() {
        // Create the extension class loader
        ClassLoader extcl;
        try {
            extcl = ExtClassLoader.getExtClassLoader();
        } catch (IOException e) {
            throw new InternalError(
                "Could not create extension class loader", e);
        }

        // Now create the class loader to use to launch the application
        try {
            loader = AppClassLoader.getAppClassLoader(extcl);
        } catch (IOException e) {
            throw new InternalError(
                "Could not create application class loader", e);
        }

        //设置AppClassLoader为线程上下文类加载器，这个文章后面部分讲解
        Thread.currentThread().setContextClassLoader(loader);
    }

/*
* Returns the class loader used to launch the main application.
*/
    public ClassLoader getClassLoader() {
        return loader;
    }
/*
* The class loader used for loading installed extensions.
*/
    static class ExtClassLoader extends URLClassLoader {}

/**
* The class loader used for loading from java.class.path.
* runs in a restricted security context.
*/
    static class AppClassLoader extends URLClassLoader {}

源码有精简，我们可以得到相关的信息。

Launcher初始化了ExtClassLoader和AppClassLoader。
Launcher中并没有看见BootstrapClassLoader，但通过System.getProperty("sun.boot.class.path")得到了字符串bootClassPath,这个应该就是BootstrapClassLoader加载的jar包路径。

我们可以先代码测试一下sun.boot.class.path是什么内容。

System.out.println(System.getProperty("sun.boot.class.path"));

得到的结果是：

C:\Program Files\Java\jre1.8.0_91\lib\resources.jar;
C:\Program Files\Java\jre1.8.0_91\lib\rt.jar;
C:\Program Files\Java\jre1.8.0_91\lib\sunrsasign.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jsse.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jce.jar;
C:\Program Files\Java\jre1.8.0_91\lib\charsets.jar;
C:\Program Files\Java\jre1.8.0_91\lib\jfr.jar;
C:\Program Files\Java\jre1.8.0_91\classes

可以看到，这些全是JRE目录下的jar包或者是class文件。

ClassLoader cl = Test.class.getClassLoader();

System.out.println("ClassLoader is:"+cl.toString());
System.out.println("ClassLoader\'s parent is:"+cl.getParent().toString());

运行结果如下：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93
ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742

这个说明，AppClassLoader的父加载器是ExtClassLoader。那么ExtClassLoader的父加载器又是谁呢？

System.out.println("ClassLoader is:"+cl.toString());
System.out.println("ClassLoader\'s parent is:"+cl.getParent().toString());
System.out.println("ClassLoader\'s grand father is:"+cl.getParent().getParent().toString());

运行如果：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93
Exception in thread "main" ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742
java.lang.NullPointerException
at ClassLoaderTest.main(ClassLoaderTest.java:13)

子主题

URLClassLoader的源码中并没有找到getParent()方法。这个方法在ClassLoader.java中。

public abstract class ClassLoader {

// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
private final ClassLoader parent;
// The class loader for the system
// @GuardedBy("ClassLoader.class")
private static ClassLoader scl;

private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;
...
}
protected ClassLoader(ClassLoader parent) {
this(checkCreateClassLoader(), parent);
}
protected ClassLoader() {
this(checkCreateClassLoader(), getSystemClassLoader());
}
public final ClassLoader getParent() {
if (parent == null)
return null;
return parent;
}
public static ClassLoader getSystemClassLoader() {
initSystemClassLoader();
if (scl == null) {
return null;
}
return scl;
}

private static synchronized void initSystemClassLoader() {
if (!sclSet) {
if (scl != null)
throw new IllegalStateException("recursive invocation");
sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
if (l != null) {
Throwable oops = null;
//通过Launcher获取ClassLoader
scl = l.getClassLoader();
try {
scl = AccessController.doPrivileged(
new SystemClassLoaderAction(scl));
} catch (PrivilegedActionException pae) {
oops = pae.getCause();
if (oops instanceof InvocationTargetException) {
oops = oops.getCause();
}
}
if (oops != null) {
if (oops instanceof Error) {
throw (Error) oops;
} else {
// wrap the exception
throw new Error(oops);
}
}
}
sclSet = true;
}
}
}

我们可以看到getParent()实际上返回的就是一个ClassLoader对象parent，
parent的赋值是在ClassLoader对象的构造方法中，它有两个情况：

由外部类创建ClassLoader时直接指定一个ClassLoader为parent。
由getSystemClassLoader()方法生成，
也就是在sun.misc.Laucher通过getClassLoader()获取，
也就是AppClassLoader。直白的说，
一个ClassLoader创建时如果没有指定parent，
那么它的parent默认就是AppClassLoader。
我们主要研究的是ExtClassLoader与AppClassLoader的parent的来源，
正好它们与Launcher类有关，
我们上面已经粘贴过Launcher的部分代码。

public class Launcher {
private static URLStreamHandlerFactory factory = new Factory();
private static Launcher launcher = new Launcher();
private static String bootClassPath =
System.getProperty("sun.boot.class.path");

public static Launcher getLauncher() {
return launcher;
}

private ClassLoader loader;

public Launcher() {
// Create the extension class loader
ClassLoader extcl;
try {
extcl = ExtClassLoader.getExtClassLoader();
} catch (IOException e) {
throw new InternalError(
"Could not create extension class loader", e);
}

// Now create the class loader to use to launch the application
try {
//将ExtClassLoader对象实例传递进去
loader = AppClassLoader.getAppClassLoader(extcl);
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}

public ClassLoader getClassLoader() {
return loader;
}
static class ExtClassLoader extends URLClassLoader {

/**
* create an ExtClassLoader. The ExtClassLoader is created
* within a context that limits which files it can read
*/
public static ExtClassLoader getExtClassLoader() throws IOException
{
final File[] dirs = getExtDirs();

try {
// Prior implementations of this doPrivileged() block supplied
// aa synthesized ACC via a call to the private method
// ExtClassLoader.getContext().

return AccessController.doPrivileged(
new PrivilegedExceptionAction<ExtClassLoader>() {
public ExtClassLoader run() throws IOException {
//ExtClassLoader在这里创建
return new ExtClassLoader(dirs);
}
});
} catch (java.security.PrivilegedActionException e) {
throw (IOException) e.getException();
}
}


/*
* Creates a new ExtClassLoader for the specified directories.
*/
public ExtClassLoader(File[] dirs) throws IOException {
super(getExtURLs(dirs), null, factory);

}
}
}

我们需要注意的是

ClassLoader extcl;

extcl = ExtClassLoader.getExtClassLoader();

loader = AppClassLoader.getAppClassLoader(extcl);

代码已经说明了问题AppClassLoader的parent是一个ExtClassLoader实例。

ExtClassLoader并没有直接找到对parent的赋值。
它调用了它的父类也就是URLClassLoder的构造方法并传递了3个参数。

public ExtClassLoader(File[] dirs) throws IOException {
super(getExtURLs(dirs), null, factory);
}

对应的代码

public URLClassLoader(URL[] urls, ClassLoader parent,
URLStreamHandlerFactory factory) {
super(parent);
}

答案已经很明了了，ExtClassLoader的parent为null。

上面张贴这么多代码也是为了说明AppClassLoader的parent是ExtClassLoader，
ExtClassLoader的parent是null。这符合我们之前编写的测试代码。

不过，细心的同学发现，
还是有疑问的我们只看到ExtClassLoader和AppClassLoader的创建，
那么BootstrapClassLoader呢？

还有，ExtClassLoader的父加载器为null,
但是Bootstrap CLassLoader却可以当成它的父加载器这又是为何呢？

我们继续往下进行。

这张图是用时序图画出来的，不过画出来的结果我却自己都觉得不理想。

大家可以看到2根箭头，
蓝色的代表类加载器向上委托的方向，
如果当前的类加载器没有查询到这个class对象已经加载就请求父加载器（不一定是父类）进行操作，
然后以此类推。直到Bootstrap ClassLoader。
如果Bootstrap ClassLoader也没有加载过此class实例，
那么它就会从它指定的路径中去查找，
如果查找成功则返回，
如果没有查找成功则交给子类加载器，
也就是ExtClassLoader,这样类似操作直到终点，
也就是我上图中的红色箭头示例。
用序列描述一下：

一个AppClassLoader查找资源时，
先看看缓存是否有，缓存有从缓存中获取，
否则委托给父加载器。
递归，重复第1步的操作。
如果ExtClassLoader也没有加载过，
则由Bootstrap ClassLoader出面，
它首先查找缓存，如果没有找到的话，
就去找自己的规定的路径下，也就是sun.mic.boot.class下面的路径。
找到就返回，没有找到，让子加载器自己去找。
Bootstrap ClassLoader如果没有查找成功，
则ExtClassLoader自己在java.ext.dirs路径中去查找，
查找成功就返回，查找不成功，
再向下让子加载器找。
ExtClassLoader查找不成功，AppClassLoader就自己查找，
在java.class.path路径下查找。找到就返回。
如果没有找到就让子类找，如果没有子类会怎么样？抛出各种异常。
上面的序列，详细说明了双亲委托的加载流程。
我们可以发现委托是从下向上，
然后具体查找过程却是自上至下。

JDK文档中是这样写的，通过指定的全限定类名加载class，它通过同名的loadClass(String,boolean)方法。

protected Class<?> loadClass(String name,  boolean resolve)  throws ClassNotFoundException

上面是方法原型，一般实现这个方法的步骤是

执行findLoadedClass(String)去检测这个class是不是已经加载过了。
执行父加载器的loadClass方法。
如果父加载器为null，则jvm内置的加载器去替代，也就是Bootstrap ClassLoader。
这也解释了ExtClassLoader的parent为null,但仍然说Bootstrap ClassLoader是它的父加载器。
如果向上委托父加载器没有加载成功，则通过findClass(String)查找。

如果class在上面的步骤中找到了，参数resolve又是true的话，
那么loadClass()又会调用resolveClass(Class)这个方法来生成最终的Class对象。
我们可以从源代码看出这个步骤。

protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，检测是否已经加载
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
//父加载器不为空则调用父加载器的loadClass
c = parent.loadClass(name, false);
} else {
//父加载器为空则调用Bootstrap Classloader
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}

if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//父加载器没有找到，则调用findclass
c = findClass(name);

// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
//调用resolveClass()
resolveClass(c);
}
return c;
}
}

代码解释了双亲委托。

编写一个类继承自ClassLoader抽象类。

复写它的findClass()方法。

在findClass()方法中调用defineClass()

这个方法在编写自定义classloader的时候非常重要，
它能将class二进制内容转换成Class对象，
如果不符合要求的会抛出各种异常。

一个ClassLoader创建时如果没有指定parent，
那么它的parent默认就是AppClassLoader。 

上面说的是，如果自定义一个ClassLoader，
默认的parent父加载器是AppClassLoader，
因为这样就能够保证它能访问系统内置加载器加载成功的class文件。

package com.frank.test;

public class Test {
    public void say(){
    System.out.println("Say Hello");
}
}

然后将它编译过年class文件Test.class放到D:\lib这个路径下

DiskClassLoader
在findClass()方法中定义了查找class的方法，然后数据通过defineClass()生成了Class对象

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;


public class DiskClassLoader extends ClassLoader {

private String mLibPath;

public DiskClassLoader(String path) {
// TODO Auto-generated constructor stub
mLibPath = path;
}

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// TODO Auto-generated method stub

String fileName = getFileName(name);

File file = new File(mLibPath,fileName);

try {
FileInputStream is = new FileInputStream(file);

ByteArrayOutputStream bos = new ByteArrayOutputStream();
int len = 0;
try {
while ((len = is.read()) != -1) {
bos.write(len);
}
} catch (IOException e) {
e.printStackTrace();
}

byte[] data = bos.toByteArray();
is.close();
bos.close();

return defineClass(name,data,0,data.length);

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

return super.findClass(name);
}

//获取要加载 的class文件名
private String getFileName(String name) {
// TODO Auto-generated method stub
int index = name.lastIndexOf('.');
if(index == -1){
return name+".class";
}else{
return name.substring(index+1)+".class";
}
}

}

测试
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class ClassLoaderTest {

public static void main(String[] args) {
// TODO Auto-generated method stub

//创建自定义classloader对象。
DiskClassLoader diskLoader = new DiskClassLoader("D:\\lib");
try {
//加载class文件
Class c = diskLoader.loadClass("com.frank.test.Test");

if(c != null){
try {
Object obj = c.newInstance();
Method method = c.getDeclaredMethod("say",null);
//通过反射调用Test类的say方法
method.invoke(obj, null);
} catch (InstantiationException | IllegalAccessException
| NoSuchMethodException
| SecurityException |
IllegalArgumentException |
InvocationTargetException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

}

}

查看Thread.java源码可以发现

public class Thread implements Runnable {

/* The context ClassLoader for this thread */
private ClassLoader contextClassLoader;

public void setContextClassLoader(ClassLoader cl) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission("setContextClassLoader"));
}
contextClassLoader = cl;
}

public ClassLoader getContextClassLoader() {
if (contextClassLoader == null)
return null;
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
ClassLoader.checkClassLoaderPermission(contextClassLoader,
Reflection.getCallerClass());
}
return contextClassLoader;
}
}

contextClassLoader只是一个成员变量，
通过setContextClassLoader()方法设置，
通过getContextClassLoader()设置。

每个Thread都有一个相关联的ClassLoader，默认是AppClassLoader。
并且子线程默认使用父线程的ClassLoader除非子线程特别设置。

initLevel从0到1的过程也就是上面说的阶段1，1到2的过程就是阶段2，2到3再到4是在阶段3里做的，3到4的过程如下：

// initializing the system class loader
VM.initLevel(3);

// system class loader initialized
ClassLoader scl = ClassLoader.initSystemClassLoader();

// set TCCL
Thread.currentThread().setContextClassLoader(scl);

// system is fully initialized
VM.initLevel(4);

Java7里的java.lang.ClassLoader#getSystemClassLoader的实现是：

public static ClassLoader getSystemClassLoader() {
initSystemClassLoader();
if (scl == null) {
return null;
}
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
checkClassLoaderPermission(scl, Reflection.getCallerClass());
}
return scl;
}

Java9里的java.lang.ClassLoader#getSystemClassLoader的实现是：

public static ClassLoader getSystemClassLoader() {
switch (VM.initLevel()) {
case 0:
case 1:
case 2:
// the system class loader is the built-in app class loader during startup
return getBuiltinAppClassLoader();
case 3:
String msg = "getSystemClassLoader should only be called after VM booted";
throw new InternalError(msg);
case 4:
// system fully initialized
assert VM.isBooted() && scl != null;
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
checkClassLoaderPermission(scl, Reflection.getCallerClass());
}
return scl;
default:
throw new InternalError("should not reach here");
}
}

Serial（英文连续）是最基本垃圾收集器，使用复制算法。
Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，
并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。
Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，
但是它简单高效，对于限 定单个 CPU 环境来说，没有线程交互的开销，
可以获得最高的单线程垃圾收集效率，
因此 Serial 垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。 

ParNew垃圾收集器其实是Serial收集器的多线程版本，也使用复制算法，
除了使用多线程进行垃圾收集之外，其余的行为和Serial收集器完全一样，
ParNew垃圾收集器在垃圾收集过程中同样也 要暂停所有其他的工作线程。


ParNew 收集器默认开启和 CPU 数目相同的线程数，
可以通过-XX:ParallelGCThreads 参数来限 制垃圾收集器的线程数。
【Parallel：平行的】 ParNew虽然是除了多线程外和Serial收集器几乎完全一样，
但是ParNew垃圾收集器是很多java 虚拟机运行在Server模式下新生代的默认垃圾收集器。 

参数

-XX:SurvivorRatio

-XX:PretenureSizeThreshold

-XX:HandlePromotionFailure

-XX:ParallelGCThreads

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，
也是一个多线程的垃 圾收集器，
它重点关注的是程序达到一个可控制的吞吐量
（Thoughput，CPU 用于运行用户代码 的时间/CPU 总消耗时间，
即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），
高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，
主要适用于在后台运算而不需要太多交互的任务。
自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别

参数

-XX:MaxGCPauseMillis

-XX:GCTimeRatio

-XX:UseAdaptiveSizePolicy

Serial Old 是 Serial 垃圾收集器年老代版本，
它同样是个单线程的收集器，使用标记-整理算法，
这个收集器也主要是运行在Client模式的java虚拟机默认的年老代垃圾收集器。

在Server模式下，主要有两个用途：
1. 在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。
2. 作为年老代中使用CMS收集器的后备垃圾收集方案。

Parallel Old收集器是Parallel Scavenge的年老代版本，
使用多线程的标记-整理算法，在JDK1.6 才开始提供。
在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，
只能保证新生代的吞吐量优先，无法保证整体的吞吐量，
Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，
如果系统对吞吐量要求比较高，
可以优先考虑新生代 Parallel Scavenge 和年老代Parallel Old收集器的搭配策略。

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，
其最主要目标是获取最短垃圾回收停顿时间，

它使用多线程的标记-清除算法。
最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。

<bean id="text" class="com.maven.Text" />

<bean id="hello" class="com.maven.Hello"><constructor-arg ref="text" /></bean>

构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参数代表一个对其他类的依赖。

例如：<bean id="hello" class="com.maven.Hello"><property name="text" ref="text" /></bean>

之所以叫setter方法注入，因为这是通过找到类的对应的setter方法，再进行相应的注入

Setter方法注入是容器通过调用无参构造器或无参static工厂 方法实例化bean之后，调用该bean的setter方法，即实现了基于setter的依赖注入。

实现方式

装配规则

（1）no：默认的方式是不进行自动装配的，通过手工设置ref属性来进行装配bean。

（2）byName：通过bean的名称进行自动装配，如果一个bean的 property 与另一bean 的name 相同，就进行自动装配。

（3）byType：通过参数的数据类型进行自动装配。

（4）constructor：利用构造函数进行装配，并且构造函数的参数通过byType进行装配。

（5）autodetect：自动探测，如果有构造方法，通过 construct的方式自动装配，否则使用 byType的方式自动装配。

能够在编译时就发现错误

因为加入singletonFactories三级缓存的前提是执行了构造器(因为要先构建出对象)，所以构造器的循环依赖没法解决。

因为Spring容器不缓存"prototype"作用域的bean，因此无法提前暴露一个创建中的bean。

通过三级缓存+ 提前曝光 解决

在createBeanInstance()之后会调用addSingleton()方法将bean注册到singletonFactories中

通过提前暴露一个单例工厂方法，从而使其他bean能够引用到该bean/提前暴露一个正在创建中的bean

Spring循环依赖的理论依据其实是Java基于值传递，传递引用，
当我们获取到对象的引用时，对象的field或者或属性是可以延后设置的。

流程图

这个Resource定位指的是BeanDefinition的资源定位，
它由ResourceLoader通过统一的Resource接口来完成，
这个Resource对各种形式的BeanDef-inition的使用都提供了统一接口。
对于这些BeanDefinition的存在形式，相信大家都不会感到陌生。
比如，
在文件系统中的Bean定义信息可以使用FileSystemResource来进行抽象；
在类路径中的Bean定义信息可以使用前面提到的ClassPathResource来使用，
等等。
这个定位过程类似于容器寻找数据的过程，就像用水桶装水先要把水找到一样。

这个载入过程是把用户定义好的Bean表示成IoC容器内部的数据结构，
而这个容器内部的数据结构就是BeanDefinition。
下面介绍这个数据结构的详细定义。
具体来说，
这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象，
通过这个BeanDefinition定义的数据结构，
使IoC容器能够方便地对POJO对象也就是Bean进行管理。

这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的。
这个注册过程把载入过程中解析得到的BeanDefinition向IoC容器进行注册。
通过分析，我们可以看到，
在IoC容器内部将BeanDefinition注入到一个HashMap中去，
IoC容器就是通过这个HashMap来持有这些BeanDefinition数据的.

创建bean

找到@Autowired的对象

创建注入对象，并赋值

子主题

BeanNameAware

BeanFactoryAware

ApplicationContextAware

由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；

Spring IoC容器中只会存在一个共享的Bean实例，无论有多少个Bean引用它，始终指向同一对象。

singleton是Bean的默认作用域

默认情况下是容器初始化的时候创建，但也可设定运行时再初始化bean

DefaultSingletonBeanRegistry类里的singletonObjects哈希表保存了单例对象。

Spring容器可以管理singleton作用域下bean的生命周期，在此作用域下，Spring能够精确地知道bean何时被创建，何时初始化完成，以及何时被销毁

每次通过Spring容器获取prototype定义的bean时，容器都将创建一个新的Bean实例，每个Bean实例都有自己的属性和状态

当容器创建了bean的实例后，bean的实例就交给了客户端的代码管理，Spring容器将不再跟踪其生命周期,并且不会管理那些被配置成prototype作用域的bean的生命周期。

对有状态的bean使用prototype作用域，而对无状态的bean使用singleton作用域。

在一次Http请求中，容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效。

在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。

在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在使用portlet context时有效。

为每个ServletContext创建一个实例。仅在Web相关的ApplicationContext中生效。

WebSocket的完整生命周期中将创建并提供一个实例。
Only valid in web-aware Spring ApplicationContext.

装载

优先加载BeanPostProcessor的实现Bean

按Bean文件和Bean的定义顺序按bean的装载顺序（即使加载多个spring文件时存在id覆盖）

“设置属性值”（第2步）时，遇到ref，则在“实例化”（第1步）之后先加载ref的id对应的bean

AbstractFactoryBean的子类，在第6步之后,会调用createInstance方法，之后会调用getObjectType方法

BeanFactoryUtils类也会改变Bean的加载顺序

Rule1：

Rule2：

Rule3：

Rule4：

Rule5:

Rule6:

在AbstractBeanFactory中
doGetBean对加载bean的不同情况进行拆分处理,
并做了部分准备工作

流程图

code

流程图

doGetBean首先尝试的是从缓存读取,分析下缓存具体是如何处理的.

逻辑是定义在DefaultSingletonBeanRegistry中,
它是AbstractBeanFactory的父类,主要职责是共享实例的注册.

这边虽然定义的是singleton,但是实际使用的时候,处理prototype,
其他scope均使用了这边进行缓存.

这边主要是需要理解
singletonObjects,
earlySingletonObjects,
singletonFactories,
registeredSingletons这4个变量.

4个变量的关系如下

code

一般情况下，Spring通过反射机制利用<bean>的class属性指定实现类实例化Bean

FactoryBean跟普通Bean不同，
其返回的对象不是指定类的一个实例，
而是该FactoryBean的getObject方法所返回的对象。
创建出来的对象是否属于单例由isSingleton中的返回决定。

FactoryBean：是一个Java Bean，
但是它是一个能生产对象的工厂Bean，
它的实现和工厂模式及修饰器模式很像。

BeanFactory：这就是一个Factory，
是一个IOC容器或者叫对象工厂，
它里面存着很多的bean。

通过 @Configuration 和 @Bean 这两个注解实现的

@Configuration 作用于类上，相当于一个xml配置文件；

@Bean 作用于方法上，相当于xml配置中的<bean>；

如何通过 PointCut 和 Advice 定位到特定的 JoinPoint 上

如何在 Advice 中编写切面代码

特定 JoinPoint 处的 Aspect 所采取的动作称为 Advice 。
Spring AOP 使用一个 Advice 作为拦截器，在 JoinPoint “周围”维护一系列的拦截器。

Before - 这些类型的 Advice 在 JoinPoint 方法之前执行，并使用 @Before 注解标记进行配置。
After Returning - 这些类型的 Advice 在连接点方法正常执行后执行，并使用 @AfterReturning 注解标记进行配置。
After Throwing - 这些类型的 Advice 仅在 JoinPoint 方法通过抛出异常退出并使用 @AfterThrowing 注解标记配置时执行。
After Finally - 这些类型的 Advice 在连接点方法之后执行，无论方法退出是正常还是异常返回，并使用 @After 注解标记进行配置。
Around - 这些类型的 Advice 在连接点之前和之后执行，并使用 @Around 注解标记进行配置

因为 Spring AOP 使用运行时代理的方式来实现 Aspect ，因此 Advised Object 总是一个代理对象(Proxied Object) 。
注意, Advised Object 指的不是原来的对象，而是织入 Advice 后所产生的代理对象。
Advice + Target Object = Advised Object = Proxy

缺点

在编译的时候就直接生成代理类

jdk动态代理