关于java:3万字Java高频面试指南带你通关跳槽季复习1个月拿下大厂offer

今日分享开始啦，请大家多多指教~

开春了，当初面试的人很多，对于面试有很多疑难。本篇文章整顿了一些面试题目材料，将一些面试经验以及网络收集的高频问题总结公布，心愿帮忙各位疾速达到面试状态。话不多说，注释开始啦~

介绍一下你简历上写的我的项目？本人次要做了什么？

你感觉我的项目里给你最大的挑战是什么？遇到了什么问题？如何解决的？从中学到了什么？

我的项目外面会一直呈现各种问题，比方数据量过大造成的内存溢出问题，如何让程序运行效率更高，如何证实咱们的算法比他人的算法效率高，如何找到新的观点来撑持咱们现有的实践，如何向导师和师兄进行沟通实现接下来的工作。

我的项目的架构图能画一下不？

感觉我的项目有哪些地方能够改良欠缺？（比方：能够加一个 redis 缓存把热点数据缓存起来）

有没有遇到过内存透露的场景?

a）过程是资源分配的最小单位，线程是工作执行的最小单位。

b）过程有本人的独立地址空间，每启动一个过程，零碎就会为它调配地址空间，建设数据表来保护代码段、堆栈段和数据段，这种操作十分低廉。而线程是共享过程中的数据的，应用雷同的地址空间，因而 CPU 切换一个线程的破费远比过程要小很多，同时创立一个线程的开销也比过程要小很多。

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

d）然而多过程程序更强壮，多线程程序只有有一个线程死掉，整个过程也死掉了，而一个过程死掉并不会对另外一个过程造成影响，因为过程有本人独立的地址空间。

a）先来先去服务

b）工夫片轮转法

c）短作业优先

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

e）优先级调度

关注音讯通信机制:

a)同步：调用一个性能，在性能后果没有返回之前，始终期待后果返回。

b)异步：调用一个性能，调用立即返回，但调用者不能立即失去后果。调用者能够持续后续的操作，其后果个别通过状态，回调函数来告诉调用者。

期待调用后果时的状态：

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

d)非阻塞：调用一个函数，不能立即失去后果之前，调用不能阻塞以后线程。一个输出操作通常包含两个阶段：

期待数据筹备好
从内核向过程复制数据

对于一个套接字上的输出操作，第一步通常波及期待数据从网络中达到。当所期待数据达到时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到利用过程缓冲区。

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 操作胜利则过程间接获取到数据。

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() 时不会再失去事件达到的告诉。

边际触发仅触发一次，程度触发会始终触发。

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)

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

b) 信号量(Semphares)：它容许同一时刻多个线程拜访同一资源，然而须要管制同一时刻拜访此资源的最大线程数量。

c) 事件(Event):Wait/Notify：通过告诉操作的形式来放弃多线程同步，还能够不便的实现多线程优先级的比拟操作。

在 Linux 中 fork 函数是十分重要的函数，它的作用是从曾经存在的过程中创立一个子过程，而原过程称为父过程。

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

调配新的内存块和内核数据结构给子过程。
将父过程局部数据结构内容拷贝至子过程。
将子过程增加到零碎过程列表。
fork 返回开始调度器，调度。

特点：

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

2)雷同然而独立的地址空间

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

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

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

fork 调用失败的起因

1)零碎中有太多过程。

2)理论用户的过程数超过限度。

协程是一种用户态的轻量级线程，协程的调度齐全由用户管制。协程领有本人的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保留到其余中央，在切回来的时候，复原先前保留的寄存器上下文和栈，间接操作栈则根本没有内核切换的开销，能够不加锁的拜访全局变量，所以上下文的切换十分快。

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

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

协程既不是过程也不是线程，协程仅仅是一个非凡的函数，协程它过程和过程不是一个维度的。

一个过程能够蕴含多个线程，一个线程能够蕴含多个协程。

一个线程内的多个协程尽管能够切换，然而多个协程是串行执行的，只能在一个线程内运行，没法利用 CPU 多核能力。

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

过程通过 fork()创立
线程通过 pthread_create() 函数创立

通过过程 id 查看占用的端口:

netstat -nap | grep 过程 id

通过端口号查看占用的过程 id :

netstat -nap | grep 端口号

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 占用率排序。

僵尸过程是指它的父过程没有期待(调用 wait/waitpid)。如果子过程先完结而父过程后完结，即子过程完结后，父过程还在持续运行然而并未调用 wait/waitpid 那子过程就会成为僵尸过程。但如果子过程后完结，即父过程先完结了，但没有调用 wait/waitpid 来期待子过程的完结，此时子过程还在运行，父过程曾经完结。那么并不会产生僵尸过程。应为每个过程完结时，零碎都会扫描以后零碎中运行的所有过程，看看有没有哪个过程时刚刚完结的这个过程的子过程，如果有就有 init 来接管它，成为它的父过程。

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

在每个过程退出的时候，内核开释该过程所有的资源，包含关上的文件，占用的内存。然而依然保留了一些信息（如过程号 pid 退出状态运行工夫等）。这些保留的信息直到过程通过调用 wait/waitpid 时才会开释。这样就导致了一个问题，如果没有调用 wait/waitpid 的话，那么保留的信息就不会开释。比方过程号就会被始终占用了。但零碎所能应用的过程号的无限的，如果产生大量的僵尸过程，将导致系统没有可用的过程号而导致系统不能创立过程。所以咱们应该防止僵尸过程。

如果过程不调用 wait / waitpid 的话，那么保留的那段信息就不会开释，其过程号就会始终被占用，然而零碎所能应用的过程号是无限的，如果大量的产生僵死过程，将因为没有可用的过程号而导致系统不能产生新的过程. 此即为僵尸过程的危害，该当防止。

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

虚拟内存使得应用程序认为它领有一个间断的地址空间，而实际上，它通常是被分隔成多个物理内存碎片，还有一部分存储在内部磁盘存储器上，在须要时进行数据交换。

虚拟内存能够让程序能够领有超过零碎物理内存大小的可用内存空间。虚拟内存让每个过程领有一片间断残缺的内存空间。

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

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

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

操作系统将内存形象成地址空间。每个程序领有本人的地址空间，这个地址空间被宰割成多个块，每一块称为一页。这些页被映射到物理内存，但不须要映射到间断的物理内存，也不须要所有页都必须在物理内存中。当程序援用到不在物理内存中的页时，会将缺失的局部从磁盘装入物理内存。

页面置换算法：

OPT 页面置换算法（最佳页面置换算法）：所抉择的被换出的页面将是最长工夫内不再被拜访，通常能够保障取得最低的缺页率。

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

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

LFU（Least Frequently Used）页面置换算法（起码应用页面置换算法）：该置换算法抉择在之前期间应用起码的页面作为淘汰页。力扣 - 实现 LFU

操作系统的内存管理机制理解吗？内存治理有哪几种形式?

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

页式治理：把主存分为大小相等且固定的一页一页的模式，页较小，绝对相比于块式治理的划分力度更大，进步了内存利用率，缩小了碎片。页式治理通过页表对应逻辑地址和物理地址。

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

段页式治理：段页式管理机制联合了段式治理和页式治理的长处。段页式管理机制就是把主存先分成若干段，每个段又分成若干页。

分段和分页：

共同点

分页机制和分段机制都是为了进步内存利用率，较少内存碎片。
页和段都是离散存储的，所以两者都是离散分配内存的形式。然而，每个页和段中的内存是间断的。

区别

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

操作系统（Operating System，简称 OS）是治理计算机硬件与软件资源的程序。依据过程拜访资源的特点，咱们能够把过程在零碎上的运行分为两个级别：

用户态(user mode) : 用户态运行的过程或能够间接读取用户程序的数据。

内核态(kernel mode): 能够简略的了解零碎态运行的过程或程序简直能够拜访计算机的任何资源，不受限制。

运行的程序根本都是运行在用户态。如果咱们调用操作系统提供的内核态级别的子性能那就须要零碎调用了。

零碎调用：与零碎态级别的资源无关的操作（如文件治理、过程管制、内存治理等)，都必须通过零碎调用形式向操作系统提出服务申请，并由操作系统代为实现。

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

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

零碎调用: 零碎调用是用户态被动要求切换到内核态的一种形式，用户应用程序通过操作系统调用内核为下层应用程序凋谢的接口来执行程序。

异样：当 cpu 在执行用户态的应用程序时，产生了某些不可知的异样。于是以后用户态的利用过程切换到解决此异样的内核的程序中去。

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

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 外围数的时候就阐明有过程在期待解决了，是负载过重。

ping : 查看与某台机器的连贯状况。TTL：生存工夫。数据报被路由器抛弃之前容许通过的网段数量。

telnet IP 地址端口

telnet 127.0.0.1 3389

为什么要用 voliate 润饰? 呈现 synchronized 为啥还须要 voliate，以及 synchronized 能保障啥？

观察者模式：观察者模式定义了一系列对象之间的一对多关系。当一个对象扭转状态, 其余依赖着都会受到告诉。车辆的数据时不断更新的，须要监控数据的变动，当有新数据时就告诉观测者 observers。

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

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

JDK 动静代理和 CGLIB 动静代理均是实现 Spring AOP 的根底。

适配器模式

什么时候疾速排序的工夫复杂度最高。讲一下什么状况该应用什么排序算法？堆排序算法如何实现？

影响排序的因素有很多，均匀工夫复杂度低的算法并不一定就是最优的。相同，有时均匀时间复杂度高的算法可能更适宜某些非凡状况。同时，抉择算法时还得思考它的可读性，以利于软件的保护。一般而言，须要思考的因素有以下四点：

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

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

c)关键字的构造及其散布状况；

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

1）当 n 较大，则应采纳工夫复杂度为 O(nlog2n)O(nlog2n) 的排序办法：疾速排序、堆排序或归并排序。

疾速排序：是目前基于比拟的外部排序中被认为是最好的办法，当待排序的关键字是随机分布时，疾速排序的均匀工夫最短；

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

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

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

3）当 n 较小，可采纳直接插入或间接抉择排序。

4）个别不应用或不间接应用传统的冒泡排序。

5）基数排序

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

a) 关键字可分解。

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

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

从以后节点开始遍历：（当入栈时拜访节点内容，则为前序遍历；出栈时拜访，则为中序遍历）

若以后节点存在，就存入栈中，并拜访左子树；

直到以后节点不存在，就出栈，并通过栈顶节点拜访右子树；

一直反复 12，直到以后节点不存在且栈空。

只须要在入栈、出栈的时候，别离进行节点拜访输入，即可别离失去前序、中序的非递归遍历代码！从以后节点开始遍历：

若以后节点存在，就存入栈中，第一次拜访，而后拜访其左子树；

直到以后节点不存在，须要回退，这里有两种状况：

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

b) 从右子树回退，这时需出栈，并取出栈节点做拜访输入。（须要留神的是，输入完毕须要置以后节点为空，以便持续回退。具体可参考代码中的 cur == null）

一直反复 12，直到以后节点不存在且栈空。

硬链接：硬连贯指通过索引节点 inode 来进行的连贯，即每一个硬链接都是一个指向对应区域的文件。

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

中断能够分为同步中断（synchronous）和异步中断(asynchronous)。

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

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

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

从实质上讲，中断 (硬) 是一种电信号，当设施有某种事件产生的时候，他就会产生中断，通过总线把电信号发送给中断控制器。如果中断的线是激活的，中断控制器就把电信号发送给处理器的某个特定引脚。处理器于是立刻进行本人正在做的事，跳到中断处理程序的入口点，进行中断解决。

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

软中断是由以后正在运行的过程所产生的。

软中断比硬中断少了一个硬件发送信号的步骤。产生软中断的过程肯定是以后正在运行的进程，因而它们不会中断 CPU。然而它们会中断调用代码的流程。如果硬件须要 CPU 去做一些事件，那么这个硬件会使 CPU 中断以后正在运行的代码。

排序二叉树尽管能够疾速检索，但在最坏的状况下：如果插入的节点集自身就是有序的，要么是由小到大排列，要么是由大到小排列，那么最初失去的排序二叉树将变成链表：所有节点只有左节点（如果插入节点集自身是大到小排列）；或所有节点只有右节点（如果插入节点集自身是小到大排列）。在这种状况下，排序二叉树就变成了一般链表，其检索效率就会很差。

红黑树

性质 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；对于红黑树，则是不会相差两倍以上。红黑树的插入删除元素的效率高于均衡二叉树，而查问时间差于均衡二叉树。红黑树的树高可能更高。

StringBuffer 是线程平安的 StringBuilder 是不平安的

根本数据类型的数组，寄存在栈内存里，间断调配对象数组, 在栈内存里的援用是间断调配的，理论数据调配在堆内存，不是间断调配的;

new Obj…()

clone()：应用 Object 类的 clone 办法。

反射

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

Object o = clazz.newInstance();

有带参数的构造函数的类，先获取到其结构对象，再通过该构造方法类获取实例：

通过反序列化来创建对象：实现 Serializable 接口。

编译时多态

办法重载都是编译时多态。依据理论参数的数据类型、个数和秩序，Java 在编译时可能确定执行重载办法中的哪一个。

办法笼罩体现出两种多态性，当对象援用本类实例时，为编译时多态，否则为运行时多态。

运行时多态

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

泛型：将类型当作参数传递给一个类或者是办法。

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

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

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

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

为现有的每一个类都编写一个对应的代理类，并且让它实现和指标类雷同的接口。

在创立代理对象时，通过结构器塞入一个指标对象，而后在代理对象的办法外部调用目标对象同名办法，并在调用前后减少一些其余办法。比方打印日志。代理对象 = 加强代码 + 指标对象。须要为每一个指标类编写对应的代理类，工作量太大了。

为其它对象提供一种代理以管制对这个对象的访问控制，在程序运行时，通过反射机制动静生成。JDK 动静代理的调用处理程序必须实现 InvocationHandler 接口，及应用 Proxy 类中的 newProxyInstance 办法动静的创立代理类。

JDK 动静代理只能只能代理实现了接口的类，而 CGLIB 能够代理未实现任何接口的类。另外，CGLIB 动静代理是通过生成一个被代理类的子类来拦挡被代理类的办法调用，因而不能代理申明为 final 类型的类和办法。就二者的效率来说，大部分状况都是 JDK 动静代理更优良，随着 JDK 版本的降级，这个劣势更加显著。

Java 语言中的类、办法、变量、参数和包等都能够注解标记，程序运行期间咱们能够获取到相应的注解以及注解中定义的内容，这样能够帮忙咱们做一些事件。比如说 Spring 中如果检测到说你的类被 @Component 注解标记的话，Spring 容器在启动的时候就会把这个类归为本人治理，这样你就能够通过 @Autowired 注解注入这个对象了。

反射介绍：

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

反射的优缺点如下：

长处：运行期类型的判断，动静加载类，进步代码灵便度。
毛病：性能瓶颈：反射相当于一系列解释操作，告诉 JVM 要做的事件，性能比间接的 Java 代码要慢很多。

平安问题，让咱们能够动静操作扭转类的属性同时也减少了类的安全隐患。

在咱们平时的我的项目开发过程中，基本上很少会间接应用到反射机制，但这不能阐明反射机制没有用，实际上有很多设计、开发都与反射机制无关。动静代理设计模式也采纳了反射机制，还有咱们日常应用的 Spring/Hibernate 等框架也大量应用到了反射机制。

咱们在应用 JDBC 连贯数据库时应用 Class.forName() 通过反射加载数据库的驱动程序；

Spring 框架的 IOC（动静加载治理 Bean）创建对象以及 AOP（动静代理）性能都和反射有分割；

动静配置实例的属性；

如果咱们动静获取到这些信息，咱们须要依附 Class 对象。Class 类对象将一个类的办法、变量等信息通知运行的程序。Java 提供了两种形式获取 Class 对象:

晓得具体类的状况下能够应用：

Class alunbarClass = TargetObject.class;

然而咱们个别是不晓得具体类的，根本都是通过遍历包上面的类来获取 Class 对象

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

Class alunbarClass1 = Class.forName(“cn.javaguide.TargetObject”);

内存透露：内存透露是指无用对象（不再应用的对象）继续占有内存或无用对象的内存得不到及时开释，从而造成内存空间的节约称为内存透露。

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 大小即可。

强援用：被强援用关联的对象不会被回收。应用 new 一个新对象的形式来创立强援用。

Object obj = new Object();

软援用：被软援用关联的对象只有在内存不够的状况下才会被回收。应用 SoftReference 类来创立软援用。

弱援用：被弱援用关联的对象肯定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。应用 WeakReference 类来创立弱援用。

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 的利用还不是很宽泛。

finalize()是 Object 的 protected 办法，子类能够笼罩该办法以实现资源清理工作，GC 在回收对象之前调用该办法。

finalize()办法中个别用于开释非 Java 资源（如关上的文件资源、数据库连贯等），或是调用非

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

防止应用的起因：

首先，因为 finalize()办法的调用机会具备不确定性，从一个对象变得不可达到开始，到 finalize()办法被执行，所破费的工夫这段时间是任意长的。咱们并不能依赖 finalize()办法能及时的回收占用的资源，可能呈现的状况是在咱们耗尽资源之前，gc 却仍未触发，因此通常的做法是提供显示的 close()办法供客户端手动调用。另外，重写 finalize()办法意味着缩短了回收对象时须要进行更多的操作，从而缩短了对象回收的工夫。

办法区中的动态变量和常量援用的对象

虚拟机栈中援用对象

本地办法栈中援用对象

类的加载：

装载：通过类的全限定名获取二进制字节流，将二进制字节流转换成办法区中的运行时数据结构，在内存中生成 Java.lang.class 对象；
链接：执行上面的校验、筹备和解析步骤，其中解析步骤是能够抉择的；
校验：查看导入类或接口的二进制数据的正确性；（文件格式验证，元数据验证，字节码验证，符号援用验证）
筹备：给类的动态变量分配内存并初始化内存空间；解析：将常量池中的符号援用转成间接援用；
初始化：激活类的动态变量的初始化 Java 代码和动态 Java 代码块，并初始化程序员设置的变量值。

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

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

最初调用的办法是 forName0 这个办法，在这个 forName0 办法中的第二个参数被默认设置为了 true，这个参数代表是否对加载的类进行初始化，设置为 true 时会类进行初始化，代表会执行类中的动态代码块，以及对动态变量的赋值等操作。

CopyOnWrite 容器：

写时复制的容器。当咱们往一个容器增加元素的时候，不间接往以后容器增加，而是先将以后容器进行 Copy，复制出一个新的容器，而后新的容器里增加元素，添加完元素之后，再将原容器的援用指向新的容器。这样做的益处是咱们能够对 CopyOnWrite 容器进行并发的读，而不须要加锁，因为以后容器不会增加任何元素。所以 CopyOnWrite 容器也是一种读写拆散的思维，读和写不同的容器。以下代码是向 ArrayList 里增加元素，能够发现在增加的时候是须要加锁的，否则多线程写的时候会 Copy 出 N 个正本进去。

读的时候不须要加锁，如果读的时候有多个线程正在向 ArrayList 增加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的 ArrayList。

CopyOnWrite 并发容器用于读多写少的并发场景。

CopyOnWrite 的毛病

CopyOnWrite 容器有很多长处，然而同时也存在两个问题，即内存占用问题和数据一致性问题。所以在开发的时候须要留神。

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

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

1、懒汉式，线程不平安

是否 Lazy 初始化：是

是否多线程平安：否

实现难度：易

形容：这种形式是最根本的实现形式，这种实现最大的问题就是不反对多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。

这种形式 lazy loading 很显著，不要求线程平安，在多线程不能失常工作。

接下来介绍的几种实现形式都反对多线程，然而在性能上有所差别。

是否 Lazy 初始化：是

是否多线程平安：是

实现难度：易

形容：这种形式具备很好的 lazy loading，可能在多线程中很好的工作，然而，效率很低，99% 状况下不须要同步。

长处：第一次调用才初始化，防止内存节约。

毛病：必须加锁 synchronized 能力保障单例，但加锁会影响效率。

getInstance() 的性能对应用程序不是很要害（该办法应用不太频繁）。

3、饿汉式

是否 Lazy 初始化：否

是否多线程平安：是

实现难度：易

形容：这种形式比拟罕用，但容易产生垃圾对象。

长处：没有加锁，执行效率会进步。

毛病：类加载时就初始化，节约内存。

它基于 classloader 机制防止了多线程的同步问题，不过，instance 在类装载时就实例化，尽管导致类装载的起因有很多种，在单例模式中大多数都是调用 getInstance 办法，然而也不能确定有其余的形式（或者其余的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的成果。

4、双检锁 / 双重校验锁（DCL，即 double-checked locking）

JDK 版本：JDK1.5 起

是否 Lazy 初始化：是

是否多线程平安：是

实现难度：较简单

形容：这种形式采纳双锁机制，平安且在多线程状况下能放弃高性能。

getInstance() 的性能对应用程序很要害。

5、注销式 / 动态外部类

是否 Lazy 初始化：是

是否多线程平安：是

实现难度：个别

形容：这种形式能达到双检锁形式一样的效用，但实现更简略。对动态域应用提早初始化，应应用这种形式而不是双检锁形式。这种形式只实用于动态域的状况，双检锁形式可在实例域须要提早初始化时应用。

这种形式同样利用了 classloader 机制来保障初始化 instance 时只有一个线程，它跟第 3 种形式不同的是：第 3 种形式只有 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 成果），而这种形式是 Singleton 类被装载了，instance 不肯定被初始化。因为 SingletonHolder 类没有被被动应用，只有通过显式调用 getInstance 办法时，才会显式装载 SingletonHolder 类，从而实例化 instance。设想一下，如果实例化 instance 很耗费资源，所以想让它提早加载，另外一方面，又不心愿在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其余的中央被被动应用从而被加载，那么这个时候实例化 instance 显然是不适合的。这个时候，这种形式相比第 3 种形式就显得很正当。

6、枚举

JDK 版本：JDK1.5 起

是否 Lazy 初始化：否

是否多线程平安：是

实现难度：易

形容：这种实现形式还没有被宽泛采纳，但这是实现单例模式的最佳办法。它更简洁，主动反对序列化机制，相对避免屡次实例化。

这种形式是 Effective Java 作者 Josh Bloch 提倡的形式，它不仅能防止多线程同步问题，而且还主动反对序列化机制，避免反序列化从新创立新的对象，相对避免屡次实例化。不过，因为 JDK1.5 之后才退出 enum 个性，用这种形式写未免让人感觉陌生，在理论工作中，也很少用。

不能通过 reflection attack 来调用公有构造方法。

Java 中的位运算符：

示意带符号右移，如：int i=15; i>>2 的后果是 3，移出的局部将被摈弃。

转为二进制的模式可能更好了解，0000 1111(15)右移 2 位的后果是 0000 0011(3)，0001 1010(18)右移 3 位的后果是 0000 0011(3)。

无符号右移：

按二进制模式把所有的数字向右挪动对应巍峨位数，低位移出（舍弃），高位的空位补零。对于负数来说和带符号右移雷同

其余构造和 >> 类似。

表达式为：

例如：

说到分层，咱们先从咱们平时应用框架开发一个后台程序来说，咱们往往会依照每一层做不同的事件的准则将零碎分为三层（简单的零碎分层可能会更多）:

Repository（数据库操作）
Service（业务操作）
Controller（数据交互）

网络分层的准则：每一层独立于其它层实现本人的工作，而不须要相互依赖，上上层之间通过规范构造来相互通信，简略易用又具备拓展性。简单的零碎须要分层，因为每一层都须要专一于一类事件。咱们的网络分层的起因也是一样，每一层只专一于做一类事件。

为什么计算机网络要分层呢？, 咱们再来较为零碎的说一说：

各层之间互相独立：各层之间互相独立，各层之间不须要关怀其余层是如何实现的，只须要晓得本人如何调用上层提供好的性能就能够了（能够简略了解为接口调用）。这个和咱们对开发时零碎进行分层是一个情理。

进步了整体灵活性：每一层都能够应用最适宜的技术来实现，你只须要保障你提供的性能以及裸露的接口的规定没有扭转就行了。这个和咱们平时开发零碎的时候要求的高内聚、低耦合的准则也是能够对应上的。

大问题化小：分层能够将简单的网络间题合成为许多比拟小的、界限比拟清晰简略的小问题来解决和解决。这样使得简单的计算机网络零碎变得易于设计，实现和标准化。这个和咱们平时开发的时候，个别会将零碎性能合成，而后将简单的问题合成为容易了解的更小的问题是绝对应的，这些较小的问题具备更好的边界（指标和接口）定义。

TCP/IP 4 层模型:

应用层
传输层
网络层
网络接口层

HTTP 协定属于应用层的协定。

HTTP 协定是基于 TCP 协定的，发送 HTTP 申请之前首先要建设 TCP 连贯也就是要经验 3 次握手。目前应用的 HTTP 协定大部分都是 1.1。在 1.1 的协定外面，默认是开启了 Keep-

Alive 的，这样的话建设的连贯就能够在屡次申请中被复用了。

另外，HTTP 协定是无状态的协定，它无奈记录客户端用户的状态 ** 个别咱们都是通过

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

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

端口：HTTP 的 URL 由“http://”起始且默认应用端口 80…

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

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

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

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

HTTP 有两种报文：申请报文和响应报文 HTTP 申请报文次要包含申请行、申请头部以及申请的数据（实体）三局部申请行（HTTP 申请报文的第一行）申请行由办法字段、URL 字段和 HTTP 协定版本字段。其中，办法字段严格辨别大小写，以后 HTTP 协定中的办法都是大写，办法字段如下介绍如下：

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

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

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

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

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

假如 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 的确认后，连贯建设。

三次握手的目标是建设牢靠的通信信道，三次握手最次要的目标就是单方确认本人与对方的发送与接管是失常的。

第三次握手是为了避免生效的连贯申请达到服务器，让服务器谬误关上连贯。

假如 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 状态。

滑动窗口：窗口是缓存的一部分，用来临时寄存字节流。发送方和接管方各有一个窗口，接收方通过 TCP 报文段中的窗口字段通知发送方本人的窗口大小，发送方依据这个值和其它信息设置本人的窗口大小。

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

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

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

拥塞管制：如果网络呈现拥塞，分组将会失落，此时发送方会持续重传，从而导致网络拥塞水平更高。因而当呈现拥塞时，该当管制发送方的速率。TCP 次要通过四个算法来进行拥塞管制：慢开始、拥塞防止、快重传、快复原。

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

慢开始与拥塞防止

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

快重传与快复原

在接管方，要求每次接管到报文段都应该对最初一个已收到的有序报文段进行确认。在发送方，如果收到三个反复确认，那么能够晓得下一个报文段失落，此时执行快重传，立刻重传下一个报文段。在这种状况下，只是失落个别报文段，而不是网络拥塞。因而执行快复原，令慢开始门限 = 拥塞窗口大小 / 2，拥塞窗口大小 = 慢开始门限，留神到此时间接进入拥塞防止。

（次要）TCP 应用超时重传来实现牢靠传输：如果一个曾经发送的报文段在超时工夫内没有收到确认，那么就重传这个报文段。

利用数据被宰割成 TCP 认为最适宜发送的数据块。

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

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

TCP 的接收端会抛弃反复的数据。

流量管制：TCP 连贯的每一方都有固定大小的缓冲空间，TCP 的接收端只容许发送端发送接收端缓冲区能接收的数据。当接管方来不及解决发送方的数据，能提醒发送方升高发送的速率，避免包失落。TCP 应用的流量控制协议是可变大小的滑动窗口协定。（TCP 利用滑动窗口实现流量管制）

拥塞管制：当网络拥塞时，缩小数据的发送。

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

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

用户数据报协定 UDP 是无连贯的，尽最大可能交付，没有拥塞管制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是增加 UDP 首部），反对一对一、一对多、多对一和多对多的交互通信。

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

TCP 利用场景：

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

UDP 利用场景：

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

UDP 为何快？

不须要建设连贯
对于收到的数据，不必给出确认
没有超时重发机制
没有流量管制和拥塞管制

MAC 地址是烧录在网卡或者接口上的物理地址，具备寰球唯一性，个别不能被扭转。IP 地址是网络中的主机或接口在网络中的逻辑地址，在同一个网络内具备唯一性。

浏览器查找域名的 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 协定拜访网页

一个电子邮件系统由三局部组成：用户代理、邮件服务器以及邮件协定。

邮件协定蕴含发送协定和读取协定，发送协定罕用 SMTP，读取协定罕用 POP3 和 IMAP。

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

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

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

用户 B 收到音讯后，关上客户端拜访 163 服务器，调用 POP3 服务。

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

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

DNS 实现的工作是：域名到 IP 地址的解析。将域名和 IP 地址互相映射的一个分布式数据库。

第一步：客户机提出域名解析申请，并将该申请发送给本地域名服务器。
第二步：当本地域名服务器收到申请后，就先查问本地缓存，如果有该纪录项，则本地域名服务器就间接把查问后果返回。
第三步：如果本地缓存中没该纪录，则本地域名服务器就间接把申请发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查问域 (根子域) 主域名服务器地址。
第四步：本地服务器再向上一步返回的域名服务器发送申请，而后承受申请的服务器查问本人的缓存，如果没该纪录，则返回相干上级域名服务器地址。
第五步：反复第四步，直到找到正确纪录。
第六步：本地域名服务器把返回后果保留到缓存，以备下一次应用，同时还将后果返回给客户机。

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

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

DNS 在区域传输的时候应用 TCP 协定, 其余时候应用 UDP 协定。

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 中。

Cookie 和 Session 都是用来跟踪浏览器用户身份的会话形式

Cookie 个别用来保留用户信息，Session 的次要作用就是通过服务端记录用户的状态

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

HTTP 是一种无状态协定。HTTP 协定本身不对申请和响应之间的通信状态进行保留。次要通过 session 机制来进行解决，Session 的次要作用就是通过服务端记录用户的状态。

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

Cookie 被禁用怎么办? 最罕用的就是利用 URL 把 Session ID 间接附加在 URL 门路的前面。

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

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

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

分布式拒绝服务，一般来说是指攻击者利用一些被管制的设施对指标网站在较短的工夫内发起大量申请，大规模耗费指标网站的主机资源，让它无奈失常服务。

ArrayList 扩容产生在 add()办法调用的时候，上面是 add()办法的源码：

ArrayList 扩容的要害办法 grow():

int newCapacity = oldCapacity + (oldCapacity >> 1); oldCapacity >> 1 右移运算符原来长度的一半再加上原长度也就是每次扩容是原来的 1.5 倍。

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

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

HashMap 是用数组 + 链表 + 红黑树进行实现的，当增加一个元素（key-value）时，就首先计算元素 key 的 hash 值，并依据 hash 值来确定插入数组中的地位，然而可能存在其余元素曾经被放在数组同一地位了，这个时候便应用链表来解决哈希抵触，当链表长度太长的时候，便将链表转换为红黑树来进步搜寻的效率。

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

数组的初始容量为 16，而容量是以 2 的次方裁减的，一是为了进步性能应用足够大的数组，二是为了能应用位运算代替取模估算。

数组是否须要裁减是通过负载因子判断的，如果以后元素个数为数组容量的 0.75 时，就会裁减数组。这个 0.75 就是默认的负载因子，可由结构传入。

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

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

底层数据结构：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，竞争会越来越强烈效率越低。

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 润饰次要是保障在数组扩容的时候保障可见性。

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

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

个别状况下，应用最多的是 HashMap。HashMap：在 Map 中插入、删除和定位元素时；TreeMap：在须要按天然程序或自定义程序遍历键的状况下；LinkedHashMap：在须要输入的程序和输出的程序雷同的状况下。

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

疾速失败 (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 还是会存在其余问题比方数据失落。

保障了不同线程对该变量操作的内存可见性。

禁止指令重排序。

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

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

volatile 能够保障线程可见性且提供了肯定的有序性，然而无奈保障原子性。在 JVM 底层是基于内存屏障实现的。

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

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

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

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

volatile 能够通过内存屏障避免指令重排序问题。硬件层面的内存屏障分为读屏障和写屏障。

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

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

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

拜访标记来分别一个办法是否申明为同步办法，从而执行相应的同步调用。

volatile 关键字是线程同步的轻量级实现，所以 volatile 性能必定比 synchronized 要害字要好。然而 volatile 关键字只能用于变量而 synchronized 关键字能够润饰办法以及代码块。synchronized 关键字在 JavaSE1.6 之后进行了次要包含为了缩小取得锁和开释锁带来的性能耗费而引入的偏差锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，理论开发中应用 synchronized 关键字的场景还是更多一些。

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

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

锁的获取过程：

通过 cas 操作来批改 state 状态，示意争抢锁的操作，如果可能获取到锁，设置以后取得锁状态的线程。compareAndSetState(0, 1)

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

通过 tryAcquire 尝试获取独占锁，如果胜利返回 true，失败返回 false。如果是同一个线程来取得锁，则间接减少重入次数，并返回 true。

如果 tryAcquire 失败，则会通过 addWaiter 办法将以后线程封装成 Node，增加到 AQS 队列尾部

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

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

锁的开释过程：

开释锁

如果锁可能被其余线程获取，唤醒后继节点中的线程。个别状况下只有唤醒后继结点的线程就行了，然而后继结点可能曾经勾销期待，所以从队列尾部往前回溯，找到离头结点最近的失常结点，并唤醒其线程。

在取得同步锁时，同步器保护一个同步队列，获取状态失败的线程都会被退出到队列中并在队列中进行自旋；移出队列（或进行自旋）的条件是前驱节点为头节点且胜利获取了同步状态。在开释同步状态时，同步器调用 tryRelease(int arg)办法开释同步状态，而后唤醒头节点的后继节点。

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()函数返回，持续后余动作。

interrupt()办法的作用实际上是：在线程受到阻塞时抛出一个中断信号，这样线程就得以退出阻塞状态。

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

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

nterrupt()办法用于中断线程。调用该办法的线程的状态为将被置为 ” 中断 ” 状态。

中断能够了解为线程的一个标识位属性，它示意一个运行中的线程是否被其余线程进行了中断操作。中断好比其余线程对该线程打了个招呼，其余线程通过调用该线程的 interrupt()办法对其进行中断操作。

留神：线程中断仅仅是置线程的中断状态位，不会进行线程。须要用户本人去监督线程的状态为并做解决。

interrupted() 检测以后线程是否曾经中断，是则返回 true，否则 false，并革除中断状态。换言之，如果该办法被间断调用两次，第二次必将返回 false，除非在第一次与第二次的霎时线程再次被中断。如果中断调用时线程曾经不处于活动状态，则返回 false。

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

在 java 中有以下 3 种办法能够终止正在运行的线程：

应用 stop 办法强行终止，然而不举荐这个办法，因为 stop 和 suspend 及 resume 一样都是过期作废的办法

应用 interrupt()办法中断线程

（非大厂会问：有哪些线程池）

升高资源耗费。通过反复利用已创立的线程升高线程创立和销毁造成的耗费。进步响应速度。当工作达到时，工作能够不须要的等到线程创立就能立刻执行。

进步线程的可管理性。线程是稀缺资源，如果无限度的创立，不仅会耗费系统资源, 还会升高零碎的稳定性，应用线程池能够进行对立的调配，调优和监控。

线程池通过 ThreadPoolExecutor 的形式过程创立

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，有限容量。

newSingleThreadExecutor：最大线程和外围线程统一，用的是 LinkedBlockingQueue，有限容量。

newCachedThreadPool：没有外围线程, 间接向 SynchronousQueue 中提交工作，如果有闲暇线程，就去取出工作执行。如果没有闲暇线程，就新建一个。执行完工作的线程有 60 秒生存工夫，如果在这个工夫内能够接到新工作，才能够存活上来。

AbortPolicy 停止策略：抛弃工作并抛出 RejectedExecutionException 异样。应用场景：这个就没有非凡的场景了，然而有一点要正确处理抛出的异样。当本人自定义线程池实例时，应用这个策略肯定要解决好触发策略时抛的异样，因为他会打断以后的执行流程。

DiscardPolicy 抛弃策略：ThreadPoolExecutor.DiscardPolicy：抛弃工作，然而不抛出异样。如果线程队列已满，则后续提交的工作都会被抛弃，且是静默抛弃。应用场景：如果你提交的工作无关紧要，你就能够应用它。

DiscardOldestPolicy 弃老策略：抛弃队列最后面的工作，而后从新提交被回绝的工作。应用场景：这个策略还是会抛弃工作，抛弃时也是毫无声息，然而特点是抛弃的是老的未执行的工作，而且是待执行优先级较高的工作。基于这个个性，能想到的场景就是，公布音讯和批改音讯，当音讯公布进来后，还未执行，此时更新的音讯又来了，这个时候未执行的音讯的版本比当初提交的音讯版本要低就能够被抛弃了。

CallerRunsPolicy 调用者运行策略：由调用线程解决该工作。应用场景：个别在不容许失败的、对性能要求不高、并发量较小的场景下应用。

线程死锁形容的是这样一种状况：多个线程同时被阻塞，它们中的一个或者全副都在期待某个资源被开释。因为线程被无限期地阻塞，因而程序不可能失常终止。如下图所示，线程 A 持有资源 2，线程 B 持有资源 1，他们同时都想申请对方的资源，所以这两个线程就会相互期待而进入死锁状态。

有效的图片地址

解决死锁的策略

死锁预防
死锁防止
死锁检测
死锁解除

死锁预防：毁坏导致死锁必要条件中的任意一个就能够预防死锁。例如：

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

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

（3）毁坏循环期待条件：按某一程序申请资源，开释资源则反序开释。

死锁防止：过程在每次申请资源时判断这些操作是否平安。

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

死锁解除：将某过程所占资源进行强制回收，而后调配给其余过程。（与死锁检测联合应用的）

通常状况下，咱们创立的变量是能够被任何一个线程拜访并批改的。如果想实现每一个线程都有本人的专属本地变量该如何解决呢？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 办法设置的值。

首先，private 润饰与 ThreadLocal 自身没有关系，private 更多是在平安方面进行思考。static 润饰这个变量，这个变量是针对一个线程内所有操作共享的，所以设置为动态变量，所有此类实例共享此动态变量，也就是说在类第一次被应用时装载，只调配一块存储空间，所有此类的对象 (只有是这个线程内定义的) 都能够操控这个变量。（设置为 static 能够防止每个线程从工作队列中获取 task 后反复创立 ThreadLocal 所关联的对象）能够解决内存泄露问题（看下一问）。

6.15 ThreadLocal 有什么缺点？如果线程池的线程应用 ThreadLocal 会有什么问题？

ThreadLocalMap 如何解决抵触？

采纳线性探测的形式。

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

在 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 的弱援用问题则不存在了。

(synchronized、juc 提供的锁如 ReentrantLock、CountDownLatch、CyclicBarrier、Semaphore 等)

偏心锁 / 非偏心锁 (重要)
可重入锁
独享锁 / 共享锁 (重要)
互斥锁 / 读写锁
乐观锁 / 乐观锁 (重要)
偏差锁 / 轻量级锁 / 重量级锁 (重要)
自旋锁

偏心锁 / 非偏心锁

偏心锁是指多个线程依照申请锁的程序来获取锁。

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

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

ke 重入锁

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

对于 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。

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

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

乐观锁在更新数据的时候，会采纳尝试更新，一直重试的形式更新数据。乐观的认为，不加锁的并发操作是没有事件的。

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

乐观锁实用于多读的利用类型，这样能够进步吞吐量。在 Java 中 java.util.concurrent.atomic 包上面的原子变量类就是应用了乐观锁的一种实现形式 CAS 实现的。

乐观锁实用于写比拟少的状况下（多读场景），个别多写的场景下用乐观锁就比拟适合，一般会常常产生抵触，这就会导致下层利用会一直的进行 retry，这样反倒是升高了性能。

小结

作为面试官的角度，会同时看技术能力（代码考核）以及我的项目经验。对于我的项目经验，倡议能够自行做一些小型我的项目，要么抉择做的很深在某个方向有很强的体现，要么就利用开源做一些有价值的我的项目。

今日份分享已完结，请大家多多包涵和指导！

1. 我的项目相干

2. 根底问题

2.1 过程和线程的区别？

2.2 过程的调度算法有哪些？（次要）

2.3 罕用 IO 模型？

2.4 select、poll 和 epoll 的区别？epoll 的底层应用的数据结构。

2.5 过程的通信形式有哪些？线程呢？

2.5.1 过程间的通信形式

2.5.2 线程间的通信形式：

2.6 fork 函数的作用？

2.7 协程的概念？

2.8. linux 过程和线程？

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

2.10 如何查看占用内存比拟多的过程？

2.11 僵尸过程产生的起因？

2.13 孤儿过程产生的起因？

2.14 讲一下虚拟内存。虚拟内存和物理内存的关系是什么？

2.15 分段和分页讲一下？以及对应的场景？

2.16 讲一下用户态和内核态？所有的零碎调用都会进入到内核态吗？

2.17 平时用什么 linux 命令比拟多？如何关上文件并进行查找某个单词？怎么在某个目录下找到蕴含 txt 的文件？

2.18 用过 ping 命令么？简略介绍一下。TTL 是什么意思？

2.19 怎么判断一个主机是不是凋谢某个端口？

2.20 说一下你最用的比拟多得模式（我说的工厂模式和观察者模式），再实现一个单例模式。

2.21 排序算法哪些是稳固的，为什么间接插入排序是稳固的，各种排序算法的工夫复杂度和空间复杂度？

2.22 如何进行二叉树的各种遍历的非递归算法实现？简要讲述。

2.23 硬链接和软链接？

2.24 中断的分类？

2.25 软中断和硬中断？

2.26 红黑树和均衡二叉树？

3 Java 根底

3.1 StringBuilder 和 StringBuffer

3.2 Java 实现间断空间的内存调配?

3.3 创建对象的形式有哪几种？

3.4 接口和抽象类有什么区别？

3.5 深拷贝和浅拷贝区别？

3.6 讲一讲封装，继承，多态（重要）。

3.7 泛型是什么? 类型擦除？

3.8 如何实现动态代理？有啥缺点？

3.9 动静代理的作用？在哪些地方用到了？（AOP、RPC 框架中都有用到，面试口试中常常要求手写一个动静代理）

3.10 JDK 的动静代理和 CGLIB 有什么区别？

3.11 谈谈对 Java 注解的了解，解决了什么问题？

3.12 Java 反射？反射有什么毛病？你是怎么了解反射的（为什么框架须要反射）？

3.13 为什么框架须要反射技术？

3.14 获取 Class 对象的两种形式

3.15 内存泄露和内存溢出的场景。

3.16 讲一下，强援用，弱援用，软援用，虚援用。

3.17 一个对象是否有虚援用的存在，不会对其生存工夫造成影响，也无奈通过虚援用 失去一个对象。

3.18 讲一下 Java 的 NIO，AIO, BIO?

3.19 Java 中 finalize()办法的应用?

3.20 GC Root 对象有哪些

3.21 Java 中 Class.forName 和 ClassLoader 的区别？

3.22 讲一下 CopyOnWriteArrayList 和 CopyOnWriteArraySet?

3.23 单例模式（重要）

3.24 Java 中 >> 和 >>> 的区别

4. 计网

4.1 为什么网络要分层？

4.2 TCP/IP 4 层模型理解么？

4.3 HTTP 是哪一层的协定？http 常见的状态码

4.4 HTTP 和 HTTPS 什么区别？

4.5 讲一下对称加密算法和非对称加密算法？

4.6 HTTP2.0 讲一下

4.7 HTTP 报文详解？具体说一下申请报文，以及 HTTP 和 TCP 的区别

4.8 TCP 三次握手的过程，以及三次握手的起因？

4.9 TCP 四次挥手的过程，以及四次挥手的起因？

4.10 TCP 滑动窗口是干什么的？TCP 的可靠性体现在哪里？拥塞管制如何实现的？

4.11 TCP 和 UDP 有什么区别？及其实用的场景。

4.12 Mac 地址和 ip 地址的区别？既然有了 Mac 地址，为什么还要 ip 地址呢？

4.13 当你关上一个电商网站，都须要经验哪些过程？别离用到了什么协定。

4.14. 电子邮件的发送过程?

4.15 DNS 解析过程，DNS 劫持理解吗？

4.16 GET 和 POST 有什么不一样？

4.17 session 和 cookie 的问题？

4.18 HTTP 是不保留状态的协定, 如何保留用户状态?

4.19 Arp 协定？

4.20 DDos 攻打理解吗？

5. 汇合框架

5.1 ArrayList 的扩容机制？

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

5.3 ConcurrentHashMap 的底层实现

5.5 什么 ConcurrentHashMap 的读操作不须要加锁？

3.17 一个对象是否有虚援用的存在，不会对其生存工夫造成影响，也无奈通过虚援用失去一个对象。