答案

2.基础问题
2.1 进程和线程的区别？
a）进程是资源分配的最小单位，线程是任务执行的最小单位。

b）进程有自己的独立地址空间，每启动一个进程，系统就会为它分配地址空间，建立数据表来维护代码段、堆栈段和数据段，这种操作非常昂贵。而线程是共享进程中的数据的，使用相同的地址空间，因此 CPU 切换一个线程的花费远比进程要小很多，同时创建一个线程的开销也比进程要小很多。

c）线程之间的通信更方便，同一进程下的线程共享全局变量、静态变量等数据，而进程之间的通信需要以通信的方式（IPC)进行。不过如何处理好同步与互斥是编写多线程程序的难点。

d）但是多进程程序更健壮，多线程程序只要有一个线程死掉，整个进程也死掉了，而一个进程死掉并不会对另外一个进程造成影响，因为进程有自己独立的地址空间。

2.2 进程的调度算法有哪些？（主要）
a）先来先去服务

b）时间片轮转法

c）短作业优先

d）多级反馈队列调度算法

e）优先级调度

2.3 常用 IO 模型？
关注消息通信机制:

a)同步：调用一个功能，在功能结果没有返回之前，一直等待结果返回。

b)异步：调用一个功能，调用立刻返回，但调用者不能立刻得到结果。调用者可以继续后续的操作，其结果一般通过状态，回调函数来通知调用者。

等待调用结果时的状态：

c)阻塞：调用一个函数，当调用结果返回之前，当前线程会被挂起，只有得到结果之后才会返回。

d)非阻塞：调用一个函数，不能立刻得到结果之前，调用不能阻塞当前线程。一个输入操作通常包括两个阶段：

1.等待数据准备好
2.从内核向进程复制数据
对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待数据到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

e）阻塞 IO 模型：应用进程被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。

f）非阻塞IO模型：进程发起 IO 系统调用后，内核返回一个错误码而不会被阻塞；应用进程可以继续执行，但是需要不断的执行系统调用来获知 I/O 是否完成。如果内核缓冲区有数据，内核就会把数据返回进程。

g）IO 复用模型：使用 select 或者 poll 等待数据，可以等待多个套接字中的任何一个变为可读。这一过程会被阻塞，当某一个套接字可读时返回，之后把数据从内核复制到进程中。（在多路复用 IO 模型中，会有一个线程不断去轮询多个 socket 的状态，只有当 socket 真正有读写事件时，才真正调用实际的 IO 读写操作。因为在多路复用 IO 模型中，只需要使用一个线程就可以管理多个 socket，并且只有在真正有 socket 读写事件进行时，才会使用 IO 资源，所以它大大减少了资源占用。）

h）信号驱动 IO 模型：当进程发起一个 IO 操作，会向内核注册一个信号处理函数，然后进程返回不阻塞；当内核数据就绪时会发送一个信号给进程，进程便在信号处理函数中调用 IO 读取数据。

i）异步 IO 模型：当进程发起一个 IO 操作，进程返回不阻塞，但也不能返回结果；内核把整个 IO 处理完后，会通知进程结果。如果IO操作成功则进程直接获取到数据。

2.4 select、poll 和 epoll 的区别？epoll 的底层使用的数据结构。
select,poll 和 epoll 允许应用程序监视一组文件描述符，等待一个或者多个描述符成为就绪状态，从而完成 I/O 操作。

select 和 poll 的功能基本相同，不过在一些实现细节上有所不同。

select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024，因此默认只能监听少于 1024 个描述符。如果要监听更多描述符的话，需要修改 FD_SETSIZE 之后重新编译；而 poll 没有描述符数量的限制，poll 中的描述符是 pollfd 类型的数组；

poll 提供了更多的事件类型，并且对描述符的重复利用上比 select 高。

如果一个线程对某个描述符调用了 select 或者 poll，另一个线程关闭了该描述符，会导致调用结果不确定。

select 和 poll 速度都比较慢，每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。

当某个进程调用 epoll_create() 方法时，内核会创建一个 eventpoll 对象。

创建 epoll 对象后，可以用 epoll_ctl() 向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理，进程调用 epoll_wait() 便可以得到事件完成的描述符。

就绪列表：epoll 使用双向链表来实现就绪队列，是一种能够快速插入和删除的数据结构。索引结构：epoll 使用红黑树去监听并维护所有文件描述符。

epoll 的描述符事件有两种触发模式：LT（水平触发）和 ET（边沿触发）。

当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait()会再次通知进程。

和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。

边沿触发仅触发一次，水平触发会一直触发。

2.5 进程的通信方式有哪些？线程呢？
2.5.1 进程间的通信方式

a) 管道/匿名管道(Pipes)：用于具有亲缘关系的父子进程间或者兄弟进程之间的通信。

b) 有名管道(Names Pipes): 匿名管道由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道。有名管道严格遵循先进先出(first in first out)。有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。

c)消息队列(Message Queuing)：消息队列是消息的链表，具有特定的格式，存放在内存中并由消息队列标识符标识。管道和消息队列的通信数据都是先进先出的原则。与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显示地删除一个消息队列时，该消息队列才会被真正的删除。消息队列可以实现消息的随机查询，消息不一定要以先进先出的次序读取，也可以按消息的类型读取.比 FIFO 更有优势。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺。

d) 信号(Signal)：信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生；（对于异常情况下的工作模式，就需要用「信号」的方式来通知进程，信号事件的来源主要有硬件来源（如键盘 Cltr+C ）和软件来源（如 kill 命令）。比如，Ctrl+C 产生 SIGINT 信号，表示终止该进程，Ctrl+Z 产生 SIGSTP，表示停止该进程，但还未结束）

e) 信号量(Semaphores)：信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。这种通信方式主要用于解决与同步相关的问题并避免竞争条件。（信号量其实是一个整型的计数器，主要用于实现进程间的互斥与同步，而不是用于缓存进程间通信的数据。）

f) 共享内存(Shared memory)：使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据的更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。可以说这是最有用的进程间通信方式。（共享内存的机制，就是拿出一块虚拟地址空间来，映射到相同的物理内存中）

h) 套接字(Sockets): 此方法主要用于在客户端和服务器之间通过网络进行通信。套接字是支持 TCP/IP 的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。

int socket(int domain, int type, int protocal)
2.5.2 线程间的通信方式：

a) 互斥量(Mutex)：采用互斥对象机制，只有拥有互斥对象的线程才有访问公共资源的权限。比如 Java 中的 synchronized 关键词和各种 Lock 都是这种机制。

b) 信号量(Semphares)：它允许同一时刻多个线程访问同一资源，但是需要控制同一时刻访问此资源的最大线程数量。

c) 事件(Event):Wait/Notify：通过通知操作的方式来保持多线程同步，还可以方便的实现多线程优先级的比较操作。

2.6 fork 函数的作用？
在 Linux 中 fork 函数是非常重要的函数，它的作用是从已经存在的进程中创建一个子进程，而原进程称为父进程。

调用 fork(),当控制转移到内核中的 fork 代码后，内核开始做：

分配新的内存块和内核数据结构给子进程。

将父进程部分数据结构内容拷贝至子进程。

将子进程添加到系统进程列表。

fork返回开始调度器，调度。

特点：

1)调用一次，返回两次并发执行

2)相同但是独立的地址空间

3)fork 的返回值：fock 函数调用一次却返回两次；向父进程返回子进程的 ID，向子进程中返回 0，

4)fork 的子进程返回为 0；

5)父进程返回的是子进程的 pid。

fork 调用失败的原因

1)系统中有太多进程。

2)实际用户的进程数超过限制。

2.7 协程的概念？
协程是一种用户态的轻量级线程，协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈，直接操作栈则基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文的切换非常快。

对操作系统而言，线程是最小的执行单元，进程是最小的资源管理单元。无论是进程还是线程，都是由操作系统所管理的。

协程不是被操作系统内核所管理的，而是完全由程序所控制，也就是在用户态执行。这样带来的好处是性能大幅度的提升，因为不会像线程切换那样消耗资源。

协程既不是进程也不是线程，协程仅仅是一个特殊的函数，协程它进程和进程不是一个维度的。

一个进程可以包含多个线程，一个线程可以包含多个协程。

一个线程内的多个协程虽然可以切换，但是多个协程是串行执行的，只能在一个线程内运行，没法利用 CPU 多核能力。

协程与进程一样，切换是存在上下文切换问题的。

2.8. linux 进程和线程？
进程通过 fork()创建

线程通过 pthread_create() 函数创建

2.9 通过进程id查看占用的端口，通过端口号查看占用的进程 id？
通过进程id查看占用的端口:

netstat -nap | grep 进程id
通过端口号查看占用的进程id :

netstat -nap | grep 端口号
2.10 如何查看占用内存比较多的进程？

ps aux | sort -k4nr | head -N
head ：-N可以指定显示的行数，默认显示10行。

ps ：a---指代所有的进程，u---userid---执行该进程的用户id，x---指代显示所有程序，不以终端机来区分。ps -aux的输出格式如下：

sort -k4nr 中：k 代表从根据哪一个关键词排序，后面的数字 4 表示按照第四列排序；n 指代 numberic sort，根据其数值排序；r 指代 reverse，这里是指反向比较结果，输出时默认从小到大，反向后从大到小。%MEM 在第 4 个位置，-k4 按照内存占用排序。%CPU 在第三个位置，-k3 表示按照cpu占用率排序。

2.11 僵尸进程产生的原因？
僵尸进程是指它的父进程没有等待(调用 wait/waitpid)。如果子进程先结束而父进程后结束，即子进程结束后，父进程还在继续运行但是并未调用 wait/waitpid 那子进程就会成为僵尸进程。但如果子进程后结束，即父进程先结束了，但没有调用 wait/waitpid 来等待子进程的结束，此时子进程还在运行，父进程已经结束。那么并不会产生僵尸进程。应为每个进程结束时，系统都会扫描当前系统中运行的所有进程，看看有没有哪个进程时刚刚结束的这个进程的子进程，如果有就有 init 来接管它，成为它的父进程。

进程设置僵尸状态的目的是维护子进程的信息，以便父进程在以后某个时间获取。要在当前进程中生成一个子进程，一般需要调用 fork 这个系统调用，fork 这个函数的特别之处在于一次调用，两次返回，一次返回到父进程中，一次返回到子进程中，可以通过返回值来判断其返回点。如果子进程先于父进程退出，同时父进程又没有调用 wait/waitpid，则该子进程将成为僵尸进程。

在每个进程退出的时候，内核释放该进程所有的资源，包括打开的文件，占用的内存。但是仍然保留了一些信息（如进程号 pid 退出状态运行时间等）。这些保留的信息直到进程通过调用 wait/waitpid 时才会释放。这样就导致了一个问题，如果没有调用 wait/waitpid 的话，那么保留的信息就不会释放。比如进程号就会被一直占用了。但系统所能使用的进程号的有限的，如果产生大量的僵尸进程，将导致系统没有可用的进程号而导致系统不能创建进程。所以我们应该避免僵尸进程。

如果进程不调用 wait / waitpid 的话，那么保留的那段信息就不会释放，其进程号就会一直被占用，但是系统所能使用的进程号是有限的，如果大量的产生僵死进程，将因为没有可用的进程号而导致系统不能产生新的进程. 此即为僵尸进程的危害，应当避免。

2.13 孤儿进程产生的原因？
孤儿进程：一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被 init 进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。孤儿进程是没有父进程的进程，管理孤儿进程这个重任就落到了 init 进程身上，因此孤儿进程并不会有什么危害。

2.14 讲一下虚拟内存。虚拟内存和物理内存的关系是什么？
虚拟内存使得应用程序认为它拥有一个连续的地址空间，而实际上，它通常是被分隔成多个物理内存碎片，还有一部分存储在外部磁盘存储器上，在需要时进行数据交换。

虚拟内存可以让程序可以拥有超过系统物理内存大小的可用内存空间。虚拟内存让每个进程拥有一片连续完整的内存空间。

局部性原理表现在以下两个方面：

1)时间局部性：如果程序中的某条指令一旦执行，不久以后该指令可能再次执行；如果某数据被访问过，不久以后该数据可能再次被访问。

2)空间局部性：一旦程序访问了某个存储单元，在不久之后，其附近的存储单元也将被访问。

操作系统将内存抽象成地址空间。每个程序拥有自己的地址空间，这个地址空间被分割成多个块，每一块称为一页。这些页被映射到物理内存，但不需要映射到连续的物理内存，也不需要所有页都必须在物理内存中。当程序引用到不在物理内存中的页时，会将缺失的部分从磁盘装入物理内存。

页面置换算法：

OPT 页面置换算法（最佳页面置换算法）：所选择的被换出的页面将是最长时间内不再被访问，通常可以保证获得最低的缺页率。

FIFO（First In First Out）页面置换算法（先进先出页面置换算法） : 总是淘汰最先进入内存的页面，即选择在内存中驻留时间最久的页面进行淘汰。

LRU （Least Currently Used）页面置换算法（最近最久未使用页面置换算法）：将最近最久未使用的页面换出。需要在内存中维护一个所有页面的链表。当一个页面被访问时，将这个页面移到链表表头。这样就能保证链表表尾的页面是最近最久未访问的。力扣-实现LRU

LFU （Least Frequently Used）页面置换算法（最少使用页面置换算法）：该置换算法选择在之前时期使用最少的页面作为淘汰页。力扣-实现LFU

2.15 分段和分页讲一下？以及对应的场景？
操作系统的内存管理机制了解吗？内存管理有哪几种方式?

块式管理：将内存分为几个固定大小的块，每个块中只包含一个进程。

页式管理：把主存分为大小相等且固定的一页一页的形式，页较小，相对相比于块式管理的划分力度更大，提高了内存利用率，减少了碎片。页式管理通过页表对应逻辑地址和物理地址。

段式管理：页式管理虽然提高了内存利用率，但是页式管理其中的页实际并无任何实际意义。段式管理把主存分为一段段的，最重要的是段是有实际意义的，每个段定义了一组逻辑信息。段式管理通过段表对应逻辑地址和物理地址。例如,有主程序段 MAIN、子程序段 X、数据段 D 及栈段 S 等。段式管理通过段表对应逻辑地址和物理地址。

段页式管理：段页式管理机制结合了段式管理和页式管理的优点。段页式管理机制就是把主存先分成若干段，每个段又分成若干页。

分段和分页：

共同点
分页机制和分段机制都是为了提高内存利用率，较少内存碎片。
页和段都是离散存储的，所以两者都是离散分配内存的方式。但是，每个页和段中的内存是连续的。

区别
页的大小是固定的，由操作系统决定；而段的大小不固定，取决于我们当前运行的程序。
分页仅仅是为了满足操作系统内存管理的需求，而段是逻辑信息的单位，在程序中可以体现为代码段，数据段，能够更好满足用户的需要。

2.16 讲一下用户态和内核态？所有的系统调用都会进入到内核态吗？
操作系统（Operating System，简称 OS）是管理计算机硬件与软件资源的程序。根据进程访问资源的特点，我们可以把进程在系统上的运行分为两个级别：

用户态(user mode) : 用户态运行的进程或可以直接读取用户程序的数据。
内核态(kernel mode):可以简单的理解系统态运行的进程或程序几乎可以访问计算机的任何资源，不受限制。
运行的程序基本都是运行在用户态。如果我们调用操作系统提供的内核态级别的子功能那就需要系统调用了。

系统调用：与系统态级别的资源有关的操作（如文件管理、进程控制、内存管理等)，都必须通过系统调用方式向操作系统提出服务请求，并由操作系统代为完成。

系统调用是操作系统为应用程序提供能够访问到内核态的资源的接口。补充：

用户态切换到内核态的几种方式

系统调用: 系统调用是用户态主动要求切换到内核态的一种方式，用户应用程序通过操作系统调用内核为上层应用程序开放的接口来执行程序。

异常：当 cpu 在执行用户态的应用程序时，发生了某些不可知的异常。于是当前用户态的应用进程切换到处理此异常的内核的程序中去。

硬件设备的中断: 当硬件设备完成用户请求后，会向 cpu 发出相应的中断信号，这时 cpu 会暂停执行下一条即将要执行的指令，转而去执行与中断信号对应的应用程序，如果先前执行的指令是用户态下程序的指令，那么这个转换过程也是用户态到内核态的转换。

2.17 平常用什么 linux 命令比较多？如何打开文件并进行查找某个单词？怎么在某个目录下找到包含 txt 的文件？
pwd：显示当前所在位置

sudo + 其他命令：以系统管理者的身份执行指令，也就是说，经由 sudo 所执行的指令就好像是 root 亲自执行。

grep：要搜索的字符串要搜索的文件 --color ：搜索命令，--color 代表高亮显示

ps - ef/ps aux：这两个命令都是查看当前系统正在运行进程，两者的区别是展示格式不同。如果想要查看特定的进程可以使用这样的格式：

ps aux|grep redis
（查看包括redis的进程），也可使用

pgrep redis -a
注意：如果直接用ps（（Process Status））命令，会显示所有进程的状态，通常结合 grep 命令查看某进程的状态。

kill -9 进程的 pid ：杀死进程（-9 表示强制终止），先用 ps 查找进程，然后用 kill 杀掉。

find 目录参数：寻找目录（查）。在/home目录下查找以 .txt 结尾的文件名:

find /home -name "*.txt"
ls 或者 ll :（ll 是 ls -l 的别名，ll 命令可以看到该目录下的所有目录和文件的详细信息）：查看目录信息。

free : 显示系统内存的使用情况，包括物理内存、交换内存(swap)和内核缓冲区内存。

tar -zcvf 打包压缩后的文件名要打包压缩的文件 : 打包并压缩文件，一般情况下打包和压缩是一起进行的，打包并压缩后的文件的后缀名一般 .tar.gz。c：压缩。

tar -xvf 压缩文件 - C 解压的位置 : 解压压缩包。x: 解压。

wget : 是从远程下载的工具。

vmstat : 虚拟内存性能监控、CPU 监控。

top : 常用来监控Linux的系统状况，比如CPU、内存的使用，显示系统上正在运行的进程。load average：系统负载，就是进程队列的长度。当这个值>cpu核心数的时候就说明有进程在等待处理了，是负载过重。

2.18 用过 ping 命令么？简单介绍一下。TTL 是什么意思？
ping : 查看与某台机器的连接情况。TTL：生存时间。数据报被路由器丢弃之前允许通过的网段数量。

2.19 怎么判断一个主机是不是开放某个端口？
telnet IP 地址端口

telnet 127.0.0.1 3389
2.20 说一下你最用的比较多得模式（我说的工厂模式和观察者模式），再实现一个单例模式。
为什么要用 voliate 修饰?出现synchronized 为啥还需要 voliate，以及 synchronized 能保证啥？

观察者模式：观察者模式定义了一系列对象之间的一对多关系。当一个对象改变状态, 其他依赖着都会受到通知。车辆的数据时不断更新的，需要监控数据的变化，当有新数据时就通知观测者observers。

迭代器模式：提供一种顺序访问聚合对象元素的方法。 hasNext() 和 next() 方法。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。

JDK 动态代理和 CGLIB 动态代理均是实现 Spring AOP 的基础。

适配器模式

2.21 排序算法哪些是稳定的，为什么直接插入排序是稳定的，各种排序算法的时间复杂度和空间复杂度？
什么时候快速排序的时间复杂度最高。讲一下什么情况该使用什么排序算法？堆排序算法如何实现？

影响排序的因素有很多，平均时间复杂度低的算法并不一定就是最优的。相反，有时平均时间复杂度高的算法可能更适合某些特殊情况。同时，选择算法时还得考虑它的可读性，以利于软件的维护。一般而言，需要考虑的因素有以下四点：

a)待排序的记录数目 n 的大小；

b)记录本身数据量的大小，也就是记录中除关键字外的其他信息量的大小；

c)关键字的结构及其分布情况；

d)对排序稳定性的要求。

1）当 n 较大，则应采用时间复杂度为 O(nlog2n)O(nlog2n) 的排序方法：快速排序、堆排序或归并排序。

快速排序：是目前基于比较的内部排序中被认为是最好的方法，当待排序的关键字是随机分布时，快速排序的平均时间最短；

堆排序：堆排序所需的辅助空间少于快速排序，并且不会出现快速排序可能出现的最坏情况，也就是排序效率稳定。

归并排序：它有一定数量的数据移动，所以我们可能过与插入排序组合，先获得一定长度的序列，然后再合并，在效率上将有所提高。

2）当 n 较大，内存空间允许，且要求稳定性 => 归并排序

3）当 n 较小，可采用直接插入或直接选择排序。

4）一般不使用或不直接使用传统的冒泡排序。

5）基数排序

它是一种稳定的排序算法，但有一定的局限性：

a) 关键字可分解。

b) 记录的关键字位数较少，如果密集更好

c) 如果是数字时，最好是无符号的，否则将增加相应的映射复杂度，可先将其正负分开排序。

2.22 如何进行二叉树的各种遍历的非递归算法实现？简要讲述。
从当前节点开始遍历：（当入栈时访问节点内容，则为前序遍历；出栈时访问，则为中序遍历）

若当前节点存在，就存入栈中，并访问左子树；

直到当前节点不存在，就出栈，并通过栈顶节点访问右子树；

不断重复 12，直到当前节点不存在且栈空。

只需要在入栈、出栈的时候，分别进行节点访问输出，即可分别得到前序、中序的非递归遍历代码！从当前节点开始遍历：

若当前节点存在，就存入栈中，第一次访问，然后访问其左子树；

直到当前节点不存在，需要回退，这里有两种情况：

a) 从左子树回退，通过栈顶节点访问其右子树（取栈顶节点用，但不出栈）

b) 从右子树回退，这时需出栈，并取出栈节点做访问输出。（需要注意的是，输出完毕需要置当前节点为空，以便继续回退。具体可参考代码中的 cur == null）

不断重复 12，直到当前节点不存在且栈空。
2.23 硬链接和软链接？
硬链接：硬连接指通过索引节点 inode 来进行的连接，即每一个硬链接都是一个指向对应区域的文件。

软链接：保存了其代表的文件的绝对路径，是另外一种文件，在硬盘上有独立的区块，访问时替换自身路径。

2.24 中断的分类？
中断可以分为同步中断（synchronous）和异步中断(asynchronous)。

中断可分为硬中断和软中断。

中断可分为可屏蔽中断（Maskable interrupt）和非屏蔽中断（Nomaskable interrupt）。

同步中断是在指令执行时由 CPU 主动产生的，受到 CPU 控制，其执行点是可控的。异步中断是 CPU 被动接收到的，由外设发出的电信号引起，其发生时间不可预测。

2.25 软中断和硬中断？
从本质上讲，中断(硬)是一种电信号，当设备有某种事情发生的时候，他就会产生中断，通过总线把电信号发送给中断控制器。如果中断的线是激活的，中断控制器就把电信号发送给处理器的某个特定引脚。处理器于是立即停止自己正在做的事，跳到中断处理程序的入口点，进行中断处理。

硬中断是由硬件产生的，比如，像磁盘，网卡，键盘，时钟等。每个设备或设备集都有它自己的 IRQ（中断请求）。

软中断是由当前正在运行的进程所产生的。

软中断比硬中断少了一个硬件发送信号的步骤。产生软中断的进程一定是当前正在运行的进程，因此它们不会中断 CPU。但是它们会中断调用代码的流程。如果硬件需要 CPU 去做一些事情，那么这个硬件会使 CPU 中断当前正在运行的代码。

2.26 红黑树和平衡二叉树？
排序二叉树虽然可以快速检索，但在最坏的情况下：如果插入的节点集本身就是有序的，要么是由小到大排列，要么是由大到小排列，那么最后得到的排序二叉树将变成链表：所有节点只有左节点（如果插入节点集本身是大到小排列）；或所有节点只有右节点（如果插入节点集本身是小到大排列）。在这种情况下，排序二叉树就变成了普通链表，其检索效率就会很差。

红黑树

性质 1：节点非红即黑。

性质 2：根节点永远是黑色的。

性质 3：所有的叶节点都是空节点（即 null），并且是黑色的。

性质 4：每个红色节点的两个子节点都是黑色。（从每个叶子到根的路径上不会有两个连续的红色节点）

性质 5：从任一节点到其子树中每个叶子节点的路径都包含相同数量的黑色节点。

红黑树最重要的性质：从根到叶子的最长的可能路径小于等于最短的可能路径的两倍长。红黑树并不是真正意义上的平衡二叉树，但在实际应用中，红黑树的统计性能要高于平衡二叉树，但极端性能略差。(对于AVL树，任何一个节点的两个子树高度差不会超过 1；对于红黑树，则是不会相差两倍以上)对于给定的黑色高度为 N 的红黑树，从根到叶子节点的最短路径长度为 N-1，最长路径长度为 2 * (N-1)2∗(N−1)。对于红黑树，插入，删除，查找的复杂度都是 O(log N)O(logN)。任何不平衡都会在3次旋转之内解决。

红黑树通过上面这种限制来保证它大致是平衡的——因为红黑树的高度不会无限增高，这样保证红黑树在最坏情况下都是高效的，不会出现普通排序二叉树的情况。

由于红黑树只是一个特殊的排序二叉树，因此对红黑树上的只读操作与普通排序二叉树上的只读操作完全相同，只是红黑树保持了大致平衡，因此检索性能比排序二叉树要好很多。

但在红黑树上进行插入操作和删除操作会导致树不再符合红黑树的特征，因此插入操作和删除操作都需要进行一定的维护，以保证插入节点、删除节点后的树依然是红黑树。

平衡二叉树的最差情形：

由平衡二叉树的定义可知，左子树和右子树最多可以相差1层高度，那么多个在同一层的子树就可以依次以相差1层的方式来递减子树的高度，如下图所示是一个拥有4棵子树的树的层高最大差情形。也就是说，一颗高度为H的平衡二叉树，其内部子树高度差最多为 [H / 2]。

红黑树的最差情形：

红黑树中红节点的父亲和孩子必须是黑节点，且从根到叶子节点经过的黑节点个数相同，因此红黑树最小深度是路径上只有黑节点，最大深度是路径上红黑节点相互间隔(重要)，因此最大深度 <=最小深度的两倍，最大深度是 2 * log2（n+1）2∗log2（n+1）。

对于 AVL 树，任何一个节点的两个子树高度差不会超过 1；对于红黑树，则是不会相差两倍以上。红黑树的插入删除元素的效率高于平衡二叉树，而查询时间差于平衡二叉树。红黑树的树高可能更高。

3 Java 基础
3.1 StringBuilder 和 StringBuffer
StringBuffer 是线程安全的 StringBuilder 是不安全的

3.2 Java实现连续空间的内存分配?
基本数据类型的数组，存放在栈内存里，连续分配对象数组,在栈内存里的引用是连续分配的，实际数据分配在堆内存，不是连续分配的;

3.3 创建对象的方式有哪几种？
new Obj..()

clone()：使用 Object 类的 clone 方法。

反射

调用 public 无参构造器，若是没有，则会报异常：

Java

Object o = clazz.newInstance();
有带参数的构造函数的类，先获取到其构造对象，再通过该构造方法类获取实例：

Java

//获取构造函数类的对象
Constroctor constroctor = User.class.getConstructor(String.class);
// 使用构造器对象的newInstance方法初始化对象
Object obj = constroctor.newInstance("name");
通过反序列化来创建对象：实现 Serializable 接口。

3.4 接口和抽象类有什么区别？
3.5 深拷贝和浅拷贝区别？
3.6 讲一讲封装，继承，多态（重要）。
编译时多态
方法重载都是编译时多态。根据实际参数的数据类型、个数和次序，Java 在编译时能够确定执行重载方法中的哪一个。

方法覆盖表现出两种多态性，当对象引用本类实例时，为编译时多态，否则为运行时多态。

运行时多态
通过父类对象引用变量引用子类对象来实现。当父类对象引用子类实例时。通过接口类型变量引用实现接口的类的对象来实现。运行时多态主要是通过继承和接口实现的。

3.7 泛型是什么?类型擦除？
泛型：将类型当作参数传递给一个类或者是方法。

类型擦除：Java 的泛型是伪泛型，这是因为 Java 在编译期间，所有的泛型信息都会被擦掉，正确理解泛型概念的首要前提是理解类型擦除。

Java 的泛型基本上都是在编译器这个层次上实现的，在生成的字节码中是不包含泛型中的类型信息的，使用泛型的时候加上类型参数，在编译器编译的时候会去掉，这个过程成为类型擦除。

原始类型: 就是擦除去了泛型信息，最后在字节码中的类型变量的真正类型，无论何时定义一个泛型，相应的原始类型都会被自动提供，类型变量擦除，并使用其限定类型（无限定的变量用 Object）替换。

Java 编译器是通过先检查代码中泛型的类型，然后在进行类型擦除，再进行编译。当具体的类型确定后，泛型提供了一种类型检测的机制，只有相匹配的数据才能正常的赋值，否则编译器就不通过。

3.8 如何实现静态代理？有啥缺陷？
为现有的每一个类都编写一个对应的代理类，并且让它实现和目标类相同的接口。

在创建代理对象时，通过构造器塞入一个目标对象，然后在代理对象的方法内部调用目标对象同名方法，并在调用前后增加一些其他方法。比如打印日志。代理对象 = 增强代码 + 目标对象。需要为每一个目标类编写对应的代理类，工作量太大了。

3.9 动态代理的作用？在哪些地方用到了？（AOP、RPC 框架中都有用到，面试笔试中经常要求手写一个动态代理）
为其它对象提供一种代理以控制对这个对象的访问控制，在程序运行时，通过反射机制动态生成。JDK动态代理的调用处理程序必须实现 InvocationHandler 接口，及使用 Proxy 类中的 newProxyInstance 方法动态的创建代理类。

3.10 JDK 的动态代理和 CGLIB 有什么区别？
JDK 动态代理只能只能代理实现了接口的类，而 CGLIB 可以代理未实现任何接口的类。另外， CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用，因此不能代理声明为 final 类型的类和方法。就二者的效率来说，大部分情况都是 JDK 动态代理更优秀，随着 JDK 版本的升级，这个优势更加明显。

3.11 谈谈对 Java 注解的理解，解决了什么问题？
Java 语言中的类、方法、变量、参数和包等都可以注解标记，程序运行期间我们可以获取到相应的注解以及注解中定义的内容，这样可以帮助我们做一些事情。比如说 Spring 中如果检测到说你的类被@Component 注解标记的话，Spring 容器在启动的时候就会把这个类归为自己管理，这样你就可以通过 @Autowired 注解注入这个对象了。

3.12 Java 反射？反射有什么缺点？你是怎么理解反射的（为什么框架需要反射）？
反射介绍：

Java 反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为 Java 语言的反射机制。

反射的优缺点如下：

优点：运行期类型的判断，动态加载类，提高代码灵活度。

缺点：

性能瓶颈：反射相当于一系列解释操作，通知 JVM 要做的事情，性能比直接的 Java 代码要慢很多。

安全问题，让我们可以动态操作改变类的属性同时也增加了类的安全隐患。

3.13 为什么框架需要反射技术？
在我们平时的项目开发过程中，基本上很少会直接使用到反射机制，但这不能说明反射机制没有用，实际上有很多设计、开发都与反射机制有关。动态代理设计模式也采用了反射机制，还有我们日常使用的 Spring／Hibernate 等框架也大量使用到了反射机制。

我们在使用 JDBC 连接数据库时使用 Class.forName() 通过反射加载数据库的驱动程序；
Spring 框架的 IOC（动态加载管理 Bean）创建对象以及 AOP（动态代理）功能都和反射有联系；
动态配置实例的属性；
3.14 获取 Class 对象的两种方式
如果我们动态获取到这些信息，我们需要依靠 Class 对象。Class 类对象将一个类的方法、变量等信息告诉运行的程序。Java 提供了两种方式获取 Class 对象:

知道具体类的情况下可以使用：

Java

Class alunbarClass = TargetObject.class;
但是我们一般是不知道具体类的，基本都是通过遍历包下面的类来获取 Class 对象

通过 Class.forName() 传入类的路径获取：

Java

Class alunbarClass1 = Class.forName("cn.javaguide.TargetObject");
3.15 内存泄露和内存溢出的场景。
内存泄漏：内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。

Java 内存泄漏的根本原因是长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄漏，尽管短生命周期对象已经不再需要，但是因为长生命周期持有它的引用而导致不能被回收，这就是 Java 中内存泄漏的发生场景。

内存溢出：指程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于 OLD 段或 Perm 段垃圾回收后，仍然无内存空间容纳新的 Java 对象的情况。

内存泄露的场景
静态集合类引起内存泄漏：静态成员的生命周期是整个程序运行期间。比如：Map 是在堆上动态分配的对象，正常情况下使用完毕后，会被 gc 回收。而如果 Map 被 static 修饰，且没有删除机制，静态成员是不会被回收的，所以会导致这个很大的 Map 一直停留在堆内存中。懒初始化 static 变量，且尽量避免使用。

当集合里面的对象属性被修改后，再调用 remove()方法时不起作用：修改 hashset 中对象的参数值，且参数是计算哈希值的字段。当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段，否则对象修改后的哈希值与最初存储进 HashSet 集合中时的哈希值就不同了。

各种连接对象( IO 流对象、数据库连接对象、网络连接对象)使用后未关闭：因为每个流在操作系统层面都对应了打开的文件句柄，流没有关闭，会导致操作系统的文件句柄一直处于打开状态，而jvm会消耗内存来跟踪操作系统打开的文件句柄。

监听器的使用：在释放对象的同时没有相应删除监听器的时候也可能导致内存泄露。

不正确使用单例模式是引起内存泄漏：单例对象在初始化后将在 JVM 的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部的引用，那么这个对象将不能被JVM正常回收，导致内存泄漏。

解决措施
尽量减少使用静态变量，类的静态变量的生命周期和类同步的。

声明对象引用之前，明确内存对象的有效作用域，尽量减小对象的作用域，将类的成员变量改写为方法内的局部变量；

减少长生命周期的对象持有短生命周期的引用；

使用 StringBuilder 和 StringBuffer 进行字符串连接，Sting 和 StringBuilder 以及 StringBuffer 等都可以代表字符串，其中 String 字符串代表的是不可变的字符串，后两者表示可变的字符串。如果使用多个 String 对象进行字符串连接运算，在运行时可能产生大量临时字符串，这些字符串会保存在内存中从而导致程序性能下降。

对于不需要使用的对象手动设置 null 值，不管 GC 何时会开始清理，我们都应及时的将无用的对象标记为可被清理的对象；

各种连接（数据库连接，网络连接，IO 连接）操作，务必显示调用 close 关闭。

内存溢出场景
JVM Heap（堆）溢出：OutOfMemoryError: Java heap space：发生这种问题的原因是 java 虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了。JVM 在启动的时候会自动设置 JVM Heap 的值，可以利用 JVM 提供的-Xmn -Xms -Xmx 等选项可进行设置。Heap的大小是新生代和老年代之和。

解决方法：

手动设置 JVM Heap（堆）的大小。
检查程序，看是否有死循环或不必要地重复创建大量对象。
Metaspace溢出：java.lang.OutOfMemoryError: Metaspace 程序中使用了大量的 jar 或 class，使 java 虚拟机装载类的空间不够，与 metaspace 大小有关。方法区用于存放 Java 类型的相关信息。在类装载器加载 class 文件到内存的过程中，虚拟机会提取其中的类型信息，并将这些信息存储到方法区。当需要存储类信息而方法区的内存占用又已经达到 -XX:MaxMetaspaceSize 设置的最大值，将会抛出 OutOfMemoryError 异常。对于这种情况的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。

解决方法:

通过 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 设置永久代大小即可。
栈溢出： java.lang.StackOverflowError : Thread Stack space：线程的方法嵌套调用层次太多(如递归调用)，以致于把栈区溢出了。

解决方法：

修改程序。
通过 -Xss: 来设置每个线程的 Stack 大小即可。
3.16 讲一下，强引用，弱引用，软引用，虚引用。
强引用：被强引用关联的对象不会被回收。使用 new 一个新对象的方式来创建强引用。

Object obj = new Object();
软引用：被软引用关联的对象只有在内存不够的情况下才会被回收。使用 SoftReference 类来创建软引用。

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null; // 使对象只被软引用关联
弱引用：被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。使用 WeakReference 类来创建弱引用。

1 Object obj = new Object();
2 WeakReference<Object> wf = new WeakReference<Object>(obj);
3 obj = null;
3.17 一个对象是否有虚引用的存在，不会对其生存时间造成影响，也无法通过虚引用得到一个对象。
3.18 讲一下 Java 的 NIO，AIO, BIO?
BIO (Blocking I/O)：

同步阻塞 I/O 模式，数据的读取写入必须阻塞在一个线程内等待其完成。

NIO (Non-blocking/New I/O):

NIO 是一种同步非阻塞的 I/O 模型，对应 java.nio 包，提供了 Channel , Selector，Buffer 等抽象。Java NIO使我们可以进行非阻塞IO操作。比如说，单线程中从通道读取数据到buffer，同时可以继续做别的事情，当数据读取到buffer中后，线程再继续处理数据。写数据也是一样的。另外，非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。JDK 的 NIO 底层由 epoll 实现。

通常来说 NIO 中的所有 IO 都是从 Channel（通道）开始的。

从通道进行数据读取：创建一个缓冲区，然后请求通道读取数据。

从通道进行数据写入：创建一个缓冲区，填充数据，并要求通道写入数据。

AIO (Asynchronous I/O)：异步非阻塞IO模型，异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。AIO 的应用还不是很广泛。

3.19 Java 中 finalize()方法的使用?
finalize()是 Object的protected 方法，子类可以覆盖该方法以实现资源清理工作，GC 在回收对象之前调用该方法。

finalize()方法中一般用于释放非 Java 资源（如打开的文件资源、数据库连接等），或是调用非

Java方法（native方法）时分配的内存（比如 C 语言的 malloc()系列函数）。

避免使用的原因：

首先，由于 finalize()方法的调用时机具有不确定性，从一个对象变得不可到达开始，到 finalize()方法被执行，所花费的时间这段时间是任意长的。我们并不能依赖 finalize()方法能及时的回收占用的资源，可能出现的情况是在我们耗尽资源之前，gc 却仍未触发，因而通常的做法是提供显示的 close()方法供客户端手动调用。另外，重写 finalize()方法意味着延长了回收对象时需要进行更多的操作，从而延长了对象回收的时间。

3.20 GC Root 对象有哪些
方法区中的静态变量和常量引用的对象

虚拟机栈中引用对象

本地方法栈中引用对象

3.21 Java 中 Class.forName 和 ClassLoader 的区别？
类的加载：

装载：通过类的全限定名获取二进制字节流，将二进制字节流转换成方法区中的运行时数据结构，在内存中生成 Java.lang.class 对象；

链接：执行下面的校验、准备和解析步骤，其中解析步骤是可以选择的；

校验：检查导入类或接口的二进制数据的正确性；（文件格式验证，元数据验证，字节码验证，符号引用验证）

准备：给类的静态变量分配内存并初始化内存空间；解析：将常量池中的符号引用转成直接引用；

初始化：激活类的静态变量的初始化 Java 代码和静态 Java 代码块，并初始化程序员设置的变量值。

在 java 中 Class.forName()和 ClassLoader 都可以对类进行加载。ClassLoader 就是遵循双亲委派模型最终调用启动类加载器的类加载器，实现的功能是通过一个类的全限定名来获取描述此类的二进制字节流，获取到二进制流后放到 JVM 中。classloader 只干一件事情，就是将 .class 文件加载到jvm中，不会执行 static 中的内容。

Class.forName() 方法实际上也是调用的 CLassLoader 来实现的。Class.forName()除了将类的 .class 文件加载到 jvm 中之外，还会对类进行初始化，执行类中的 static 块。

@CallerSensitive
public static Class<?> forName(String className)throws ClassNotFoundException {
Class<?> caller = Reflection.getCallerClass();
return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
}
最后调用的方法是 forName0 这个方法，在这个 forName0 方法中的第二个参数被默认设置为了 true，这个参数代表是否对加载的类进行初始化，设置为 true 时会类进行初始化，代表会执行类中的静态代码块，以及对静态变量的赋值等操作。

3.22 讲一下 CopyOnWriteArrayList 和 CopyOnWriteArraySet?
CopyOnWrite 容器：
写时复制的容器。当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行 Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对 CopyOnWrite 容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以 CopyOnWrite 容器也是一种读写分离的思想，读和写不同的容器。以下代码是向 ArrayList 里添加元素，可以发现在添加的时候是需要加锁的，否则多线程写的时候会 Copy 出N个副本出来。

Java

public boolean add(T 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();
}
}

final void setArray(Object[] a) {
array = a;
}
读的时候不需要加锁，如果读的时候有多个线程正在向 ArrayList 添加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的 ArrayList。

Java

public E get(int index) {
return get(getArray(), index);
}
CopyOnWrite 并发容器用于读多写少的并发场景。

CopyOnWrite 的缺点
CopyOnWrite容器有很多优点，但是同时也存在两个问题，即内存占用问题和数据一致性问题。所以在开发的时候需要注意。

内存占用问题。因为 CopyOnWrite 的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象（注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。如果这些对象占用的内存比较大，比如说 200M 左右，那么再写入 100M 数据进去，内存就会占用 300M，那么这个时候很有可能造成频繁的 Yong GC 和 Full GC。针对内存占用问题，可以通过压缩容器中的元素的方法来减少大对象的内存消耗，比如，如果元素全是10进制的数字，可以考虑把它压缩成36进制或64进制。或者不使用 CopyOnWrite 容器，而使用其他的并发容器，如 ConcurrentHashMap。

数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

3.23 单例模式（重要）
下述内容来源于菜鸟教程

Java

/*
1、懒汉式，线程不安全
是否 Lazy 初始化：是
是否多线程安全：否
实现难度：易
描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
*/
public class Singleton {
private static Singleton instance;
private Singleton (){}

public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}

//接下来介绍的几种实现方式都支持多线程，但是在性能上有所差异。

/*
2、懒汉式，线程安全
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：易
描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。
*/
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
/*
3、饿汉式
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述：这种方式比较常用，但容易产生垃圾对象。
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。
它基于 classloader 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
*/
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
/*
4、双检锁/双重校验锁（DCL，即 double-checked locking）
JDK 版本：JDK1.5 起
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：较复杂
描述：这种方式采用双锁机制，安全且在多线程情况下能保持高性能。
getInstance() 的性能对应用程序很关键。
*/
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
/*
5、登记式/静态内部类
是否 Lazy 初始化：是
是否多线程安全：是
实现难度：一般
描述：这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。
这种方式同样利用了 classloader 机制来保证初始化 instance 时只有一个线程，它跟第 3 种方式不同的是：第 3 种方式只要 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 效果），而这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 SingletonHolder 类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，这种方式相比第 3 种方式就显得很合理。
*/
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
/*
6、枚举
JDK 版本：JDK1.5 起
是否 Lazy 初始化：否
是否多线程安全：是
实现难度：易
描述：这种实现方式还没有被广泛采用，但这是实现单例模式的最佳方法。它更简洁，自动支持序列化机制，绝对防止多次实例化。
这种方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。不过，由于 JDK1.5 之后才加入 enum 特性，用这种方式写不免让人感觉生疏，在实际工作中，也很少用。
不能通过 reflection attack 来调用私有构造方法。
*/
public enum Singleton {
INSTANCE;
public void whateverMethod() {
}
}
3.24 Java 中>>和>>>的区别
Java 中的位运算符：

>>表示带符号右移，如：int i=15; i>>2 的结果是 3，移出的部分将被抛弃。
转为二进制的形式可能更好理解，0000 1111(15)右移 2 位的结果是 0000 0011(3)，0001 1010(18)右移 3 位的结果是 0000 0011(3)。

>>>无符号右移：
按二进制形式把所有的数字向右移动对应巍峨位数，低位移出（舍弃），高位的空位补零。对于正数来说和带符号右移相同，对于负数来说不同。
其他结构和>>相似。

表达式为：

Java

result = exp1 >> exp2;

result = exp2 >>> exp2;
表示把数 exp1 向右移动 exp2 位。

例如：

Java

// 20的二进制为0000 0000 0000 0000 0000 0000 0001 0100，右移2位后为0000 0000 0000 0000 0000 0000 0000 0101，则结果就为 res = 5;
res = 20 >> 2;
//-20的二进制为其正数的补码加1，即1111 1111 1111 1111 1111 1111 1110 1100，右移2位，高位补1，最后补码变为1111 1111 1111 1111 1111 1111 1111 1011，即 res = -5;
res = -20 >> 2;
//而对于>>>符号而言：
//正数结果与 >> 相同；
res = 20 >>> 2;
//-20的二进制为 1110 1100，右移2位，此时高位补0，即0011 1111 1111 1111 1111 1111 1111 1011，此时该数为正，结果为 res = 1073741819;
res = -20 >>> 2;
4. 计网
4.1 为什么网络要分层？
说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层可能会更多）:

Repository（数据库操作）

Service（业务操作）

Controller（数据交互）

网络分层的原则：每一层独立于其它层完成自己的工作，而不需要相互依赖，上下层之间通过标准结构来互相通信，简单易用又具有拓展性。复杂的系统需要分层，因为每一层都需要专注于一类事情。我们的网络分层的原因也是一样，每一层只专注于做一类事情。

为什么计算机网络要分层呢？ ,我们再来较为系统的说一说：

各层之间相互独立：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。这个和我们对开发时系统进行分层是一个道理。
提高了整体灵活性：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
** 大问题化小** ：分层可以将复杂的网络间题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。
4.2 TCP/IP 4 层模型了解么？
TCP/IP 4 层模型:

应用层

传输层

网络层

网络接口层

4.3 HTTP 是哪一层的协议？http常见的状态码
HTTP 协议属于应用层的协议。

HTTP 协议是基于 TCP 协议的，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-

Alive 的，这样的话建立的连接就可以在多次请求中被复用了。

另外， HTTP协议是无状态的协议，它无法记录客户端用户的状态** 一般我们都是通过

Session 来记录客户端用户的状态。

常见的状态码： 200、301、302、403、404、500、503

COde Description
200 请求被成功处理
301 永久性重定向比如建设一个网站后，将网站的url变换了，重新申请一个域名，
但是希望之前的用户访问之前url仍然可以访问到，
就可以做一个重定向新的url下面。
比如京东最早域名www.360buy.com名重定向到现在www.jd.com
302 临时性重定向比如用户在未登录时访问个人中心页面，这时可以临时重定向到登录的url。
304 Not Modified 当客户端拥有可能过期的缓存时，
会携带缓存的标识 etag、时间等信息询问服务器缓存是否仍可复用，
而304是告诉客户端可以复用缓存。
400 请求出错由于语法格式有误，服务器无法理解此请求。不作修改，客户程序就无法重复此请求。
401 未授权（未授权）请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403 没有访问权限系统中某些页面只有在某些权限下才能访问，
当用户去访问了一个本身没有访问权限的url，回报403错误。
404 没有对应资源一般是自己输入了一个url，这个url并不合法。
404 找不到，Web 服务器找不到您所请求的文件或脚本。
请检查URL 以确保路径正确。
405 不允许此方法 405 不允许此方法，对于请求所标识的资源，
不允许使用请求行中所指定的方法。
(get/post/put/delete/请求用混淆了，更正即可)
请确保为所请求的资源设置了正确的 MIME 类型
406 不可接受根据此请求中所发送的“接受”标题，
此请求所标识的资源只能生成内容特征为“不可接受”的响应实体
407 需要代理身份验证 407 需要代理身份验证，在可为此请求提供服务之前，
您必须验证此代理服务器。请登录到代理服务器，然后重试
412 前提条件失败在服务器上测试前提条件时，
部分请求标题字段中所给定的前提条件估计为FALSE。
客户机将前提条件放置在当前资源 metainformation（标题字段数据）中，
以防止所请求的方法被误用到其他资源
414 Request-URI 太长 414 Request-URI 太长，Request-URL太长，服务器拒绝服务此请求。
仅在下列条件下才有可能发生此条件：
1. 客户机错误地将 POST 请求转换为具有较长的查询信息的 GET 请求
2. 客户机遇到了重定向问题（例如，指向自身的后缀的重定向前缀）
3. 服务器正遭受试图利用某些服务器
（将固定长度的缓冲区用于读取或执行 Request-URI）
中的安全性漏洞的客户干扰
500 服务器错误比如服务器某一个函数代码出错了，有没有捕获异常，这时候会报500错误。
500 服务器的内部错误，Web 服务器不能执行此请求。请稍后重试此请求。
501 未实现 501 未实现，Web 服务器不支持实现此请求所需的功能。请检查URL 中的错误
502 网关出错 Bad Gateway
网关出错，当用作网关或代理时，
服务器将从试图实现此请求时所访问的upstream 服务器中接收无效的响应
503 服务器停机系统正在维护或者服务器暂停的时候，回报500错误。
504 Gateway Timeout 代理服务器无法及时的从上游获得响应
4.4 HTTP 和 HTTPS 什么区别？
端口：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL之上的HTTP协议，SSL运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

4.5 讲一下对称加密算法和非对称加密算法？
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

非对称密钥加密，加密和解密使用不同的密钥。通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。可以更安全地将公开密钥传输给通信发送方；运算速度慢。典型的非对称加密算法有RSA、DSA等

HTTPS 采用的加密方式: HTTPS 采用混合的加密机制。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。

4.6 HTTP2.0讲一下
4.7 HTTP报文详解？详细说一下请求报文，以及HTTP和TCP的区别
HTTP有两种报文：请求报文和响应报文HTTP请求报文主要包括请求行、请求头部以及请求的数据（实体）三部分请求行（HTTP请求报文的第一行）请求行由方法字段、URL字段和HTTP协议版本字段。其中，方法字段严格区分大小写，当前HTTP协议中的方法都是大写，方法字段如下介绍如下：

请求头部：位于请求行的下面, 是一个个的key-value值

空行(CR+LF)：请求报文用空行表示header和请求数据的分隔请求数据**：GET方法没有携带数据， POST方法会携带一个body

HTTP的响应报文包括：状态行，响应头部，相应的数据(响应体)

状态行包括：HTTP版本号，状态码和状态值组成。响应头类似请求头，是一系列key-value值

空白行：同上，响应报文也用空白行来分隔header和数据响应体：响应的数据

4.8 TCP三次握手的过程，以及三次握手的原因？
假设 A 为客户端，B 为服务器端。

首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。

A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。

B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。

A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。B 收到 A 的确认后，连接建立。

三次握手的目的是建立可靠的通信信道，三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

4.9 TCP四次挥手的过程，以及四次挥手的原因？
假设 A 为客户端，B 为服务器端。

A 发送连接释放报文，FIN=1。

B 收到之后发出确认，它发回一个 ACK确认报文，确认序号为收到的序号加1。此时TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。

当 B 不再需要连接时，发送连接释放报文，FIN=1。

A 收到后发出ACK 确认报文，并将确认序号设置为收到序号加1，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。

B 收到 A 的确认后释放连接。

CLOSE-WAIT 状态问题：

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送FIN 连接释放报文。

TIME-WAIT 状态问题(这个问题问过很多次但总是答得不甚满意)：

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。

4.10 TCP滑动窗口是干什么的？TCP的可靠性体现在哪里？拥塞控制如何实现的？
滑动窗口：窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。接收窗口只会对窗口内最后一个按序到达的字节进行确认。如果发送窗口内的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向滑动接收窗口。

流量控制如何实现：流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

拥塞控制：如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量。

慢开始与拥塞避免
发送的最初执行慢开始，令拥塞窗口大小为1，发送方只能发送1个报文段；当收到确认后，将拥塞窗口大小加倍。设置一个慢开始门限，当拥塞窗口的大小大于慢开始门限时，进入拥塞避免，每个轮次只将拥塞窗口加1。如果出现了超时，则令慢开始门限 = 拥塞窗口大小 / 2，然后重新执行慢开始。

快重传与快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令慢开始门限 = 拥塞窗口大小 / 2 ，拥塞窗口大小 = 慢开始门限，注意到此时直接进入拥塞避免。

（主要）TCP使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

应用数据被分割成 TCP 认为最适合发送的数据块。

TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

TCP 的接收端会丢弃重复的数据。

流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）

拥塞控制：当网络拥塞时，减少数据的发送。

ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

4.11 TCP和UDP有什么区别？及其适用的场景。
用户数据报协议 UDP是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。

传输控制协议 TCP是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。

TCP应用场景：

效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输、接受邮件、远程登录。

UDP应用场景：

效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话、广播通信（广播、多播）。

UDP为何快？

不需要建立连接
对于收到的数据，不用给出确认
没有超时重发机制
没有流量控制和拥塞控制
4.12 Mac 地址和 ip 地址的区别？既然有了 Mac 地址，为什么还要 ip 地址呢？
MAC地址是烧录在网卡或者接口上的物理地址，具有全球唯一性，一般不能被改变。IP地址是网络中的主机或接口在网络中的逻辑地址，在同一个网络内具有唯一性。

4.13 当你打开一个电商网站，都需要经历哪些过程？分别用到了什么协议。
浏览器查找域名的IP地址（DNS：获取域名对应的IP）

浏览器向web服务器发送HTTP请求（cookies会随着请求发送给服务器）

服务器处理请求（请求处理请求参数、cookies、生成一个HTML响应）

服务器返回HTTP报文，发回一个HTML响应。

浏览器解析渲染页面，浏览器开始显示HTML。

连接结束

使用的协议:

DNS: 获取域名对应的IP TCP: 与服务器建立TCP连接

IP: 建立TCP协议时，需要发送数据，发送数据在网络层上使用IP协议

OSPF：IP数据包在路由器之间，路由选择使用OSPF协议

ARP：路由器在与服务器进行通信的过程中，将IP地址装换成MAC地址

HTTP：客户端浏览器与Web服务器之间的应用层通信协议，在TCP建立完成后，使用HTTP协议访问网页

4.14. 电子邮件的发送过程?
一个电子邮件系统由三部分组成：用户代理、邮件服务器以及邮件协议。

邮件协议包含发送协议和读取协议，发送协议常用 SMTP，读取协议常用 POP3 和 IMAP。

用户A的邮箱是QQ邮箱，他要发往的邮箱是163邮箱，用户A写好一封邮件点击发送，即提交到了QQ邮箱服务器，使用的是SMTP协议。

QQ邮箱会对A发送邮件的收件地址进行解析，判断是否为内部邮箱的账号，如果也是QQ邮箱，会直接存储到自己的存储空间，如果不是则会发送到指定邮箱服务器，使用的也是SMTP协议。

163的邮箱服务器收到邮件后会再次判断该邮件是否为自己的邮件，如果是则存到自己的存储空间，等待POP3服务去读取邮件。

用户B收到消息后，打开客户端访问163服务器，调用POP3服务。

Pop3服务接到指令后，读取存储空间中发送给B的未读邮件服务。

将读取到的邮件返回给客户端软件。

4.15 DNS解析过程，DNS劫持了解吗？
DNS完成的工作是：域名到IP地址的解析。将域名和IP地址相互映射的一个分布式数据库。第一步：客户机提出域名解析请求，并将该请求发送给本地域名服务器。

第二步：当本地域名服务器收到请求后，就先查询本地缓存，如果有该纪录项，则本地域名

服务器就直接把查询结果返回。

第三步：如果本地缓存中没该纪录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域(根子域)主域名服务器地址。

第四步：本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没该纪录，则返回相关下级域名服务器地址。

第五步：重复第四步，直到找到正确纪录。

第六步：本地域名服务器把返回结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

DNS劫持：在DNS服务器中，将www..com的域名对应的IP地址进行了变化。你解析出来的域名对应的IP，在劫持前后不一样。

HTTP劫持：你DNS解析的域名的IP地址不变。在和网站交互过程中的劫持了你的请求。在网站发给你信息前就给你返回了请求。

DNS在区域传输的时候使用TCP协议,其他时候使用UDP协议。

4.16 GET和POST有什么不一样？
GET和POST是HTTP请求的两种基本方法（记不住全部，只记这么点）

GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST么有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
4.17 session和cookie的问题？
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式

Cookie 一般用来保存用户信息，Session 的主要作用就是通过服务端记录用户的状态

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将Cookie 信息加密然后使用到的时候再去服务器端解密。

4.18 HTTP是不保存状态的协议,如何保存用户状态?
HTTP 是一种无状态协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。主要通过session机制来进行解决，Session 的主要作用就是通过服务端记录用户的状态。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办**?** 最常用的就是利用 URL 把 Session ID 直接附加在URL路径的后面。

4.19 Arp协议？
Arp协议能通过接收端的ip地址解析到mac地址。

如果发送端和目标端的主机都在同一个网段，发送端发送数据帧前检查是否拥有接收端的 mac地址，如果没有，则启动arp，先检查缓存ip-mac表中是否有接收端的mac地址，如果有则直接拿来即用，如果没有则在本网段（局域网）广播arp包，本网段各计算机都收到arp请求，从发送来的数据中检查请求过来的ip地址与自己是否一致，如果不一致，则丢弃，如果 ip一致，则单播返回mac地址给请求的计算机，发送端便获取到了接收端的mac地址，接收到接收端的mac地址它还会缓存一份，用于下次拿来即用。

如果请求端和目标端的主机不在同一个网段呢？arp广播的数据是被路由阻断的，不能跨到不同的网段进行广播的，因为这样广播会导致广播数据泛滥。如果不在同一个网段，则请求端拿到的目标端的mac地址其实是它网关的mac地址，将数据帧给到网关再进行下一跳转发，下一跳同样在自己的网段寻找到目标主机mac地址或再找到下一跳mac地址。

4.20 DDos攻击了解吗？
分布式拒绝服务，一般来说是指攻击者利用一些被控制的设备对目标网站在较短的时间内发起大量请求，大规模消耗目标网站的主机资源，让它无法正常服务。

5. 集合框架
5.1 ArrayList的扩容机制？
ArrayList扩容发生在add()方法调用的时候，下面是add()方法的源码：

public boolean add(E e) {
//扩容
ensureCapacityInternal(size + 1); //Increments modCount!!
elementData[size++] = e;
return true;
}
ArrayList扩容的关键方法grow():

private void grow(int minCapacity) {
// 获取到ArrayList中elementData数组的内存空间长度
int oldCapacity = elementData.length;
// 扩容至原来的1.5倍
int newCapacity = oldCapacity + (oldCapacity >> 1);
// 再判断一下新数组的容量够不够，够了就直接使用这个长度创建新数组，不够就将数组长度设置为需要的长度
if (newCapacity - minCapacity < 0)
newCapacity = minCapacity;
//若预设值大于默认的最大值检查是否溢出
if (newCapacity - MAX_ARRAY_SIZE > 0)
newCapacity = hugeCapacity(minCapacity);
// 调用Arrays.copyOf方法将elementData数组指向新的内存空间时newCapacity的连续空间
// 并将elementData的数据复制到新的内存空间
elementData = Arrays.copyOf(elementData, newCapacity);
}
int newCapacity = oldCapacity + (oldCapacity >> 1); oldCapacity >> 1 右移运算符原来长度的一半再加上原长度也就是每次扩容是原来的1.5倍。

之前的所有都是确定新数组的长度，确定之后就是把老数组copy到新数组中，这样数组的扩容就结束了。

以上的一切都是ArrayList扩容的第一步，第二步就没啥说的了，就是把需要添加的元素添加到数组的最后一位。

5.2 HashMap 的底层实现、JDK 1.8 的时候为啥将链表转换成红黑树？HashMap 的负载因子
HashMap 和 Hashtable 的区别？HashMap如何实现扩容？

HashMap是用数组+链表+红黑树进行实现的，当添加一个元素（key-value）时，就首先计算元素key的hash值，并根据hash值来确定插入数组中的位置，但是可能存在其他元素已经被放在数组同一位置了，这个时候便使用链表来解决哈希冲突，当链表长度太长的时候，便将链表转换为红黑树来提高搜索的效率。

HashMap是基于拉链法实现的一个散列表，内部由数组和链表和红黑树实现。

数组的初始容量为16，而容量是以2的次方扩充的，一是为了提高性能使用足够大的数组，二是为了能使用位运算代替取模预算。

数组是否需要扩充是通过负载因子判断的，如果当前元素个数为数组容量的0.75时，就会扩充数组。这个0.75就是默认的负载因子，可由构造传入。

为了解决碰撞，数组中的元素是单向链表类型。当链表长度到达一个阈值时（>=8），会将链表转换成红黑树提高性能。而当链表长度缩小到另一个阈值时（<=6），又会将红黑树转换回单向链表提高性能，这里是一个平衡点。

当个数不多的时候，直接链表遍历更方便，实现起来也简单。而红黑树的实现要复杂的多。

5.3 ConcurrentHashMap的底层实现
底层数据结构： JDK1.7的 ConcurrentHashMap 底层采用分段的数组+链表实现，JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。Hashtable 和 JDK1.8 之前的 HashMap 的底层数据结构类似都是采用数组+链表的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的；

实现线程安全的方式（重要）：

① 在JDK1.7的时候，ConcurrentHashMap（分段锁）对整个桶数组进行了分割分段(Segment)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。到了 JDK1.8 的时候已经摒弃了Segment的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6以后对 synchronized锁做了很多优化）整个看起来就像是优化过且线程安全的 HashMap，虽然在JDK1.8中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本；synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。(TreeBin: 红黑二叉树节点 Node: 链表节点)

② Hashtable(同一把锁) :使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。

5.5 什么 ConcurrentHashMap 的读操作不需要加锁？
ConcurrentHashMap 在jdk1.7中是采用Segment + HashEntry + ReentrantLock的方式进行实现的，而1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS +

Synchronized来保证并发安全进行实现。

总结：定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，而不会读到过期的值。由于get操作中只需要读不需要写共享变量，所以可以不用加锁。之所以不会读到过期的值，依据Java内存模型的happen before原则，对volatile字段的写入操作先于读操作，get总能拿到最新的值。

get操作全程不需要加锁是因为Node的成员val是用volatile修饰的和数组用volatile修饰没有关系。

数组用volatile修饰主要是保证在数组扩容的时候保证可见性。

5.6 HashMap，LinkedHashMap，TreeMap 有什么区别？HashMap ，TreeMap，
LinkedHashMap使用场景？

LinkedHashMap 保存了记录的插入顺序，在用 Iterator 遍历时，先取到的记录肯定是先插入的；遍历比 HashMap 慢；

TreeMap 实现 SortMap 接口，能够把它保存的记录根据键排序（默认按键值升序排序，也可以指定排序的比较器）

一般情况下，使用最多的是 HashMap。HashMap：在 Map 中插入、删除和定位元素时；TreeMap：在需要按自然顺序或自定义顺序遍历键的情况下； LinkedHashMap：在需要输出的顺序和输入的顺序相同的情况下。

5.7 有哪些集合是线程不安全的，又有哪些集合是线程不安全的？怎么解决呢？线程安全的集合类.
Vector Stack Hashtable

java.util.concurrent包下所有的集合类（ConcurrentHashMap，CopyOnWriteArrayList和CopyOnWriteArraySet等）

5.8 什么是快速失败(fail-fast)、能举个例子吗？什么是安全失败(fail-safe)呢？
快速失败(fail-fast)

快速失败(fail-fast)是 Java 集合的一种错误检测机制。在使用迭代器对集合进行遍历的时候，我们在多线程下操作非安全失败(fail-safe)的集合类可能就会触发 fail-fast 机制，导致抛出ConcurrentModificationException 异常。另外，在单线程下，如果在遍历过程中对集合对象的内容进行了修改的话也会触发 fail-fast 机制。

举个例子：多线程下，如果线程 1 正在对集合进行遍历，此时线程 2 对集合进行修改（增加、删除、修改），或者线程 1 在遍历过程中对集合进行修改，都会导致线程 1 抛出异常。

安全失败(fail-safe)

采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。所以，在遍历过程中对原集合所作的修改并不能被迭代器检测到，故不会抛 ConcurrentModificationException

5.8 HashMap 多线程操作导致死循环问题异常
主要原因在于并发下的 rehash 会造成元素之间会形成一个循环链表。不过，jdk 1.8 后解决了这个问题，但是还是不建议在多线程下使用 HashMap，因为多线程下使用 HashMap 还是会存在其他问题比如数据丢失。

6 多线程
6.1 在多线程情况下如何保证线程安全。
6.2 写一个死锁的例子

public class DeadLock implements Runnable {
public int flag = 1;//静态对象是类的所有对象共享的
private static Object o1 = new Object(), o2 = new Object();
@Override
public void run() {
System.out.println("flag=" + flag);
if (flag == 1) {
synchronized (o1) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (o2) {
System.out.println("1");
}
}
}
if (flag == 0) {
synchronized (o2) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (o1) {
System.out.println("0");
}
}
}

}

public static void main(String[] args) {

DeadLock td1 = new DeadLock();
DeadLock td2 = new DeadLock();
td1.flag = 1;
td2.flag = 0;
//td1,td2都处于可执行状态，但JVM线程调度先执行哪个线程是不确定的。
//td2的run()可能在td1的run()之前运行new Thread(td1).start();newThread(td2).start();
}
}
6.3 讲一下volatile关键字的作用。
1. 保证了不同线程对该变量操作的内存可见性。

2. 禁止指令重排序。

当写一个volatile变量时，JMM将本地内存更改的变量写回到主内存中。

当取一个volatile变量时，JMM将使线程对应的本地内存失效，然后线程将从主内存读取共享变量。

volatile 可以保证线程可见性且提供了一定的有序性，但是无法保证原子性。在 JVM 底层是基于内存屏障实现的。

当对非 volatile 变量进行读写的时候，每个线程先从内存拷贝变量到 CPU 缓存中。如果计算机有多个CPU，每个线程可能在不同的 CPU 上被处理，这意味着每个线程可以拷贝到不同的本地内存中。

而声明变量是 volatile 的，JVM 保证了每次读变量都从内存中读，跳过本地内存这一步，所以就不会有可见性问题

对 volatile 变量进行写操作时，会在写操作后加一条 store 屏障指令，将工作内存中的共享变量刷新回主内存；

对 volatile 变量进行读操作时，会在读操作前加一条 load屏障指令，从主内存中读取共享变量；

volatile可以通过内存屏障防止指令重排序问题。硬件层面的内存屏障分为读屏障和写屏障。

对于读屏障来说，在指令前插入读屏障，可以让高速缓存中的数据失效，强制重新从主内存加载数据。

对于写屏障来说，在指令后插入写屏障，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。

6.4 synchronized 作用，讲一讲底层实现。
synchronized关键字解决的是多个线程之间访问资源的同步性，调用操作系统内核态做同步，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

在 Java 早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

synchronized关键字最主要的三种使用方式：

修饰实例方法**:** 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁

修饰静态方法**:** 也就是给当前类加锁，会作用于类的所有对象实例。因为访问静态synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

修饰代码块**:** 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

synchronized 关键字底层原理属于 JVM 层面。

① synchronized 同步语句块的情况：synchronized 同步语句块的实现使用的是monitorenter和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

② synchronized 修饰方法的的情况：JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

6.5 ReetrantLock 和 synchronized的区别
6.6 说说 synchronized关键字和 volatile关键字的区别
volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized关键字要好。但是volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块。synchronized关键字在JavaSE1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，实际开发中使用 synchronized 关键字的场景还是更多一些。

多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。

volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

6.7 ReetrantLock实现方式
锁的获取过程：

通过cas操作来修改state状态，表示争抢锁的操作，如果能够获取到锁，设置当前获得锁状态的线程。compareAndSetState(0, 1)

如果没有获取到锁，尝试去获取锁。acquire(1)。

通过tryAcquire尝试获取独占锁，如果成功返回true，失败返回false。如果是同一个线程来获得锁，则直接增加重入次数，并返回true。

如果tryAcquire失败，则会通过addWaiter方法将当前线程封装成Node，添加到AQS队列尾部

acquireQueued，将Node作为参数，通过自旋去尝试获取锁。（如果前驱为head才有资格进行锁的抢夺。）

如果获取锁失败，则挂起线程。

锁的释放过程：

释放锁

如果锁能够被其他线程获取，唤醒后继节点中的线程。一般情况下只要唤醒后继结点的线程就行了，但是后继结点可能已经取消等待，所以从队列尾部往前回溯，找到离头结点最近的正常结点，并唤醒其线程。

在获得同步锁时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

####6.8 AQS原理

AQS是一个用来构建锁和同步器的框架。AQS核心思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。

AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。AQS使用CAS对该同步状态进行原子操作实现对其值的修改。

状态信息通过protected类型的getState，setState，compareAndSetState进行操作。

AQS定义两种资源共享方式

Exclusive（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：

Share（共享）：多个线程可同时执行。

以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state 会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

6.9 interrupt，interrupted与isInterrupted方法的区别? 如何停止一个正在运行的线程
interrupt()方法的作用实际上是：在线程受到阻塞时抛出一个中断信号，这样线程就得以退出阻塞状态。

interrupted()调用的是currentThread().isInterrupted(true)方法，即说明是返回当前线程的是否已经中断的状态值，而且有清理中断状态的机制。测试当前线程是否已经中断，线程的中断状态由该方法清除。即如果连续两次调用该方法，则第二次调用将返回false（在第一次调用已清除flag后以及第二次调用检查中断状态之前，当前线程再次中断的情况除外）所以，interrupted()方法具有清除状态flag的功能

isInterrupted()调用的是isInterrupted(false)方法，意思是返回线程是否已经中断的状态，它没有清理中断状态的机制。

interrupt() 方法用于中断线程。调用该方法的线程的状态为将被置为"中断"状态。

中断可以理解为线程的一个标识位属性，它表示一个运行中的线程是否被其他线程进行了中断操作。中断好比其他线程对该线程打了个招呼，其他线程通过调用该线程的interrupt()方法对其进行中断操作。

注意：线程中断仅仅是置线程的中断状态位，不会停止线程。需要用户自己去监视线程的状态为并做处理。

interrupted() 检测当前线程是否已经中断，是则返回true，否则false，并清除中断状态。换言之，如果该方法被连续调用两次，第二次必将返回false，除非在第一次与第二次的瞬间线程再次被中断。如果中断调用时线程已经不处于活动状态，则返回false。

isInterrupted() 检测当前线程是否已经中断，是则返回true，否则false。中断状态不受该方法的影响。如果中断调用时线程已经不处于活动状态，则返回false。

在java中有以下3种方法可以终止正在运行的线程：

使用stop方法强行终止，但是不推荐这个方法，因为stop和suspend及resume一样都是过期作废的方法

使用interrupt()方法中断线程

6.10 线程池作用？Java 线程池有哪些参数？阻塞队列有几种？拒绝策略有几种？线程池的工作机制？
（非大厂会问：有哪些线程池）

降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。提高响应速度。当任务到达时，任务可以不需要的等到线程创建就能立即执行。

提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源,还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

线程池通过 ThreadPoolExecutor 的方式进程创建

1 public ThreadPoolExecutor(int corePoolSize,
2 int maximumPoolSize,
3 long keepAliveTime,
4 TimeUnit unit,
5 BlockingQueue<Runnable> workQueue,
6 ThreadFactory threadFactory,
7 RejectedExecutionHandler handler)

3 个最重要的参数：

corePoolSize : 核心线程数线程数定义了最小可以同时运行的线程数量。

maximumPoolSize : 当队列中存放的任务达到队列容量的时候，当前可以同时运行的线程数量变为最大线程数。

workQueue : 当新任务来的时候会先判断当前运行的线程数量是否达到核心线程数，如果达到的话，新任务就会被存放在队列中。

ThreadPoolExecutor 其他常见参数:

keepAliveTime :当线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了keepAliveTime 才会被回收销毁；
unit：keepAliveTime参数的时间单位。
threadFactory：executor 创建新线程的时候会用到。
handler：饱和策略。关于饱和策略下面单独介绍一下。
阻塞队列有几种

用来保存等待被执行的任务的阻塞队列，且任务必须实现Runable接口，在JDK中提供了如下阻塞队列：

1、ArrayBlockingQueue（有界队列）：基于数组结构的有界阻塞队列，按FIFO排序任务；

2、LinkedBlockingQuene（有/无界队列（基于链表的，传参就是有界，不传就是无界）：基于链表结构的阻塞队列，按FIFO排序任务，吞吐量通常要高于ArrayBlockingQuene；

3、SynchronousQuene（同步移交队列（需要一个线程调用put方法插入值，另一个线程调用take方法删除值））：一个不存储元素的阻塞队列，每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQuene；

4、PriorityBlockingQuene（具有优先级的、无限阻塞队列）：具有优先级的无界阻塞队列；

ThreadPoolExecutor饱和策略定义:

如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任时， ThreadPoolTaskExecutor 定义一些策略:

ThreadPoolExecutor.AbortPolicy ：抛出 RejectedExecutionException 来拒绝新任务的处理。

ThreadPoolExecutor.CallerRunsPolicy ：调用执行自己的线程运行任务。也就是直接在调用execute 方法的线程中运行( run )被拒绝的任务，如果执行程序已关闭，则会丢弃该任务。因此这种策略会降低对于新任务提交速度，影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话，你可以选择这个策略。

ThreadPoolExecutor.DiscardPolicy ：不处理新任务，直接丢弃掉。

ThreadPoolExecutor.DiscardOldestPolicy ：此策略将丢弃最早的未处理的任务请求。

线程池的工作过程

提交任务后，线程池先判断线程数是否达到了核心线程数（corePoolSize）。如果未达到线程数，则创建核心线程处理任务；否则，就执行下一步；

接着线程池判断任务队列是否满了。如果没满，则将任务添加到任务队列中；否则，执行下一步；

接着因为任务队列满了，线程池就判断线程数是否达到了最大线程数。如果未达到，则创建非核心线程处理任务；否则，就执行饱和策略，默认会抛出RejectedExecutionException异常。

常见线程池

newFixedThreadPool：最大线程和核心线程一致，用的是LinkedBlockingQueue，无限容量。

public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
}
newSingleThreadExecutor：最大线程和核心线程一致，用的是LinkedBlockingQueue，无限容量。

public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()));
}
newCachedThreadPool：没有核心线程,直接向 SynchronousQueue 中提交任务，如果有空闲线程，就去取出任务执行。如果没有空闲线程，就新建一个。执行完任务的线程有 60 秒生存时间，如果在这个时间内可以接到新任务，才可以存活下去。

public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
}
newScheduledThreadPool：核心线程和最大线程都有，采用DelayedWorkQueue 队列。

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
return new ScheduledThreadPoolExecutor(corePoolSize);
}
public ScheduledThreadPoolExecutor(int corePoolSize) {
super(corePoolSize, Integer.MAX_VALUE, DEFAULT_KEEPALIVE_MILLIS, MILLISECONDS, new DelayedWorkQueue());
}
private static final long DEFAULT_KEEPALIVE_MILLIS = 10L;
6.11 线程池拒绝策略分别使用在什么场景?
AbortPolicy中止策略：丢弃任务并抛出RejectedExecutionException异常。使用场景：这个就没有特殊的场景了，但是有一点要正确处理抛出的异常。当自己自定义线程池实例时，使用这个策略一定要处理好触发策略时抛的异常，因为他会打断当前的执行流程。

DiscardPolicy丢弃策略：ThreadPoolExecutor.DiscardPolicy：丢弃任务，但是不抛出异常。如果线程队列已满，则后续提交的任务都会被丢弃，且是静默丢弃。使用场景：如果你提交的任务无关紧要，你就可以使用它。

DiscardOldestPolicy弃老策略：丢弃队列最前面的任务，然后重新提交被拒绝的任务。使用场景：这个策略还是会丢弃任务，丢弃时也是毫无声息，但是特点是丢弃的是老的未执行的任务，而且是待执行优先级较高的任务。基于这个特性，能想到的场景就是，发布消息和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。

CallerRunsPolicy调用者运行策略：由调用线程处理该任务。使用场景：一般在不允许失败的、对性能要求不高、并发量较小的场景下使用。

6.12 线程死锁，解除线程死锁有哪几种方式？(两次栽倒这题上了，时间太久又忘记了，如何解决很重要)
线程死锁描述的是这样一种情况：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会互相等待而进入死锁状态。

无效的图片地址

解决死锁的策略
死锁预防

死锁避免

死锁检测

死锁解除

死锁预防：破坏导致死锁必要条件中的任意一个就可以预防死锁。例如：

（1）破坏保持和等待条件：一次性申请所有资源，之后不再申请资源，如果不满足资源条件则得不到资源分配。

（2）破坏不可剥夺条件：当一个进程获得某个不可剥夺的资源时，提出新的资源申请，若不满足，则释放所有资源。

（3）破坏循环等待条件：按某一顺序申请资源，释放资源则反序释放。

死锁避免：进程在每次申请资源时判断这些操作是否安全。

死锁检测：判断系统是否属于死锁的状态，如果是，则执行死锁解除策略。

死锁解除：将某进程所占资源进行强制回收，然后分配给其他进程。（与死锁检测结合使用的）

6.13 ThreadLocal 是什么，应用场景是什么，原理是怎样的？
通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？ JDK 中提供的ThreadLocal 类正是为了解决这样的问题。 ThreadLocal 类主要解决的就是让每个线程绑定自己的值，可以将 ThreadLocal 类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个 ThreadLocal 变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是 ThreadLocal 变量名的由来。他们可以使用 get()和 set() 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。 ThreadLocal 最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在ThreadLocal上， ThreadLocal 可以理解为只是ThreadLocalMap 的封装，传递了变量ThreadLocalMap 值。我们可以把ThrealLocal理解为ThreadLocal 类实现的定制化的 HashMap 。类中可以通过Thread.currentThread() 获取到当前线程对象后，直接通过getMap(Thread t) 可以访问到该线程的ThreadLocalMap 对象。每个 Thread 中都具备一个 ThreadLocalMap ，而 ThreadLocalMap 可以存储以ThreadLocal 为 key ，Object对象为 value 的键值对。

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {}
比如我们在同一个线程中声明了两个 ThreadLocal 对象的话，会使用 Thread 内部都是使用仅有那个ThreadLocalMap 存放数据的， ThreadLocalMap 的 key 就是 ThreadLocal 对象，value 就是ThreadLocal 对象调用set 方法设置的值。

6.14 ThreadLocal类为什么要加上private static修饰？
首先，private修饰与ThreadLocal本身没有关系，private更多是在安全方面进行考虑。static 修饰这个变量，这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。（设置为static可以避免每个线程从任务队列中获取task后重复创建ThreadLocal所关联的对象）可以解决内存泄露问题（看下一问）。

6.15 ThreadLocal有什么缺陷？如果线程池的线程使用ThreadLocal会有什么问题？
ThreadLocalMap如何解决冲突？

采用线性探测的方式。

public class Thread implements Runnable {
......
ThreadLocal.ThreadLocalMap threadLocals = null;
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
......
}

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。所以，如果没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来， ThreadLocalMap 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 set() 、 get() 、 remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal 方法后最好手动调用remove() 方法。

static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}

在ThreadLocalMap中，也是用Entry来保存K-V结构数据的。但是Entry中key只能是ThreadLocal对象，这点被Entry的构造方法已经限定死了。Entry继承自WeakReference（弱引用，生命周期只能存活到下次GC前），但只有Key是弱引用类型的， Value并非弱引用。由于ThreadLocalMap的key是弱引用，而Value是强引用。这就导致了一个问题，ThreadLocal在没有外部对象强引用时，发生GC时弱引用Key会被回收，而Value不会回收。当线程没有结束，但是ThreadLocal已经被回收，则可能导致线程中存在ThreadLocalMap<null, Object>的键值对，造成内存泄露。（ ThreadLocal被回收，ThreadLocal关联的线程共享变量还存在）。

为了防止此类情况的出现，我们有两种手段：

1、使用完线程共享变量后，显示调用ThreadLocalMap.remove()方法清除线程共享变量；

既然Key是弱引用，那么我们要做的事，就是在调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots 分析后就变成不可达了，下次GC的时候就可以被回收。

2、JDK建议ThreadLocal定义为private static，这样ThreadLocal的弱引用问题则不存在了。

6.16 介绍一下 Java 有哪些锁
(synchronized、juc 提供的锁如 ReentrantLock、CountDownLatch、CyclicBarrier、Semaphore等)

公平锁/非公平锁 (重要)

可重入锁

独享锁/共享锁 (重要)

互斥锁/读写锁

乐观锁/悲观锁 (重要)

偏向锁/轻量级锁/重量级锁 (重要)

自旋锁

公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。

对于Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。

对于Java ReentrantLock而言，是一个可重入锁，其名字是Re entrant Lock重新进入锁。

对于Synchronized而言，也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。

独享锁/共享锁 (互斥锁/读写锁)

独享锁是指该锁一次只能被一个线程所持有。共享锁是指该锁可被多个线程所持有。

对于Java ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。

上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。互斥锁在Java中的具体实现就是ReentrantLock

读写锁在Java中的具体实现就是ReadWriteLock

乐观锁/悲观锁

乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。

对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

乐观锁在更新数据的时候，主要就是两个步骤：冲突检测和数据更新。乐观的认为，不加锁的并发操作是没有事情的。当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。

悲观锁在Java中的使用，就是利用各种锁。

乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

CAS包含三个参数 CAS（V,E,N）。V表示要更新的变量，E表示预期的值，N表示新值。仅当要更新的变量值等于预期的值时，才会将要更新的变量值的值设置成新值，否则什么都不做。

偏向锁/轻量级锁/重量级锁

这三种锁是指锁的状态，并且是针对Synchronized。

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。

轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。

自旋锁

自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

6.17 乐观锁和悲观锁讲一下，哪些地方用到。
乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。

悲观锁对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

乐观锁在更新数据的时候，会采用尝试更新，不断重试的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。

共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程，传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，数据库的for update SQL语句。Java中synchronized 和ReentrantLock 等独占锁就是悲观锁思想的实现。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中java.util.concurrent.atomic 包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

乐观锁适用于写比较少的情况下（多读场景），一般多写的场景下用悲观锁就比较合适，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能。

作者：啦啦啦
链接：https://leetcode-cn.com/circle/discuss/XXGdoF/
来源：力扣（LeetCode）
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

posted on 2021-02-20 13:15 清浊阅读(152) 评论(0) 编辑收藏举报