参考

第一部分：

详细的介绍JVM的内存模型结构
JVM最常用的参数配置讲讲
GC垃圾收集算法、GC垃圾收集器有哪些，以及新生代老生代 分别用什么算法
多线程的几种加锁方式详细介绍
实现线程安全的方式？ThreadLocal原理？线程池了解吗说说看？自己用线程池怎么定参数？
HashMap底层实现，哈希冲突怎么解决的
ConcurrentHashMap 在Java7和Java8中的区别？为什么Java8并发效率更好？什么情况下用HashMap，什么情况用ConcurrentHashMap？
MySQL采用了什么存储引擎，为什么？
各种排序算法讲一下
二面
索引的类型，索引的底层实现原理
MySQL数据库对应的行锁、表锁、悲观锁、乐观锁的区别
MySQL数据库引擎？应用场景？查询优化？NoSQL有用或了解吗？
mysql事务讲一下，事务定义，四个性质，事务并发引起的问题，事务的四个隔离级别
Spring IoC、AOP，底层代码看过吗，scope作用域为什么要有prototype
谈谈你知道的设计模式，知道什么是回调模式吗
高并发系统，海量数据分库分表的策略，怎么来实现
数据库前面的Redis缓存，如何实现查询的负载均衡
为什么选择阿里巴巴？你对待工作的做事原则有哪些？
三面：
选一个项目具体讲讲背景、你的职责、遇到的困难以及如何解决（然后各种问细节）
Redis你了解多少？5种对象，8种数据结构，RDB和AOF持久化区别
Redis和数据库如何保证数据一致性
谈谈你对分布式的理解，分布式场景会面临哪些技术调整和挑战？
介绍Nginx负载均衡策略？
谈谈异步和同步的使用场景，以及消息队列。
四面（交叉面）：

1. 你参与的项目，画出对应的架构设计图。

2. 如果让你设计秒杀，你的设计思路。

3. 谈谈MySQL的查询优化方法，重点谈谈优化步骤。

4. 用过什么代码质量检测工具？谈谈你对代码注释的规范

5. 用过什么JVM调优命令？

6. 如何实现线程安全？java的线程安全类？讲讲线程池

7. 讲讲生产者消费者模式

8. 谈谈你对SOA以及微服务的理解，之间的区别。

HR面：
9. 前面的面试有什么收获吗？

10. 你回顾自己的项目，有哪一点是最遗憾的最想改进的？具体讲讲

11. 你有什么技术方面崇拜的人吗？

12. 为什么要选择阿里，你对阿里的印象是什么样？

13. 你平时是怎么积累技术的？

14. 你在技术方面的未来规划

---

第二部分：

ISO模型与协议
http1.0：需要使用keep-alive参数来告知服务器端要建立一个长连接
http1.1：默认长连接。支持只发送header信息，可以用作权限请求。支持Host域。
http2.0：多路复用的技术，做到同一个连接并发处理多个请求。HTTP2.0使用HPACK算法对header的数据进行压缩。支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。
会话层:负责管理主机之间的会话进程，负责建立、管理、终止进程之间的会话。
传输层:将上层数据分段并提供端到端的、可靠的或不可靠的传输，还要处理端到端的差错控制和流量控制问题。协议TCP、UDP、SPX
网络层:对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能。协议IP、IPX、RIP、OSPF
数据链路层:在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。协议SDLC、HDLC、PPP、STP、帧中继
TCPIP模型与协议
应用层：单位是数据段，协议有FTP、TELNET、HTTP、SMTP、SNMP、TFTP、NTP、DNS
运输层：单位是数据包，协议有TCP、UDP
网络层：单位是数据帧，协议有IP
网络接口层：单位是比特，ARP、RARP
三次握手与四次挥手
BIO NIO AIO
BIO：同步阻塞IO，每个请求都要一个线程来处理。
NIO：同步非阻塞IO，一个线程可以处理多个请求，适用于短连接、小数据。
AIO：异步非阻塞IO，一个线程处理多个请求，使用回调函数实现，适用于长连接、大数据。
DDOS攻击原理与防御方式
HTTP Get Flood：发送大量会产生sql查询的连接，使得数据库负载很高。
CSRF跨站请求伪造原理攻击者盗用了你的身份，以你的名义发送恶意请求。
CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
防御方式：1.验证码；2. 后台生成token，让前端请求携带。3.使用对称加密，后端随机给前端一个密钥，前端进行加密，后端解密。
会话劫持通过暴力破解、 预测、窃取（通过XSS攻击）等方式获取到用户session
XSS攻击XSS攻击是Web攻击中最常见的攻击方法之一，它是通过对网页注入可执行代码且成功地被浏览器执行，达到攻击的目的，形成了一次有效XSS攻击，一旦攻击成功，它可以获取用户的联系人列表，然后向联系人发送虚假诈骗信息，可以删除用户的日志等等，有时候还和其他攻击方式同时实施比如SQL注入攻击服务器和数据库、Click劫持、相对链接劫持等实施钓鱼，它带来的危害是巨大的，是web安全的头号大敌。
XSS反射型攻击，恶意代码并没有保存在目标网站，通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击的。
XSS存储型攻击，恶意代码被保存到目标网站的服务器中，这种攻击具有较强的稳定性和持久性，比较常见场景是在博客，论坛等社交网站上，但OA系统，和CRM系统上也能看到它身影，比如：某CRM系统的客户投诉功能上存在XSS存储型漏洞，黑客提交了恶意攻击代码，当系统管理员查看投诉信息时恶意代码执行，窃取了客户的资料，然而管理员毫不知情，这就是典型的XSS存储型攻击。
解决方法
在表单提交或者url参数传递前，对需要的参数进行过滤
过滤用户输入。检查用户输入的内容中是否有非法内容。如<>（尖括号）、”（引号）、 ‘（单引号）、%（百分比符号）、;（分号）、()（括号）、&（& 符号）、+（加号）等
28.RPC与HTTP服务的区别

数据库原理
MYISAM与innodb搜索引擎原理MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。其采用索引文件与数据文件，索引文件只存放索引，叶子节点存放数据的物理地址。数据文件存放数据。其索引方式是非聚集的。
InnoDB也使用B+Tree作为索引结构。但是它的主索引与数据都放在一个文件中。这种索引叫做聚集索引，因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
区别一：InnoDB的主索引与数据都放在一个文件中。而MYISAM是分开存放的。
区别二：InnoDB的辅助索引data域存储相应记录主键的值而不是地址。
区别三：InnoDB的主键索引是聚集索引，而MYISAM不是聚集索引。
3.索引，聚簇索引和二级索引的加锁区别

聚集（clustered）索引，也叫聚簇索引。数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。
非聚集（unclustered）索引。该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。会发生二次查询。
稠密索引:稠密索引文件中的索引块保持键的顺序与文件中的排序顺序一致。
稀疏索引:稀疏索引没有为每个数据都创建一个索引,它比稠密索引节省了更多的存储空间，但查找给定值的记录需更多的时间。只有当数据文件是按照某个查找键排序时，在该查找键上建立的稀疏索引才能被使用，而稠密索引则可以应用在任何的查找键。
联合索引:将一张表中多个列组成联合索引(col1,col2,col3)，其生效方式满足最左前缀原则。
覆盖索引:对于二级索引而言，在innodb中一般是需要先根据二级索引查询到主键，然后在根据一级索引查询到数据。但是如果select的列都在索引中，就避免进行一级查询。
4.主键选择

在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键。
where 1 = 1:能够方便我们拼sql，但是使用了之后就无法使用索引优化策略，因此会进行全表扫描，影响效率。
5.分表分库

水平拆分：依据表中的数据的逻辑关系，将同一个表中的数据依照某种条件拆分到多台数据库（主机）上面。按照1个或多个字段以及相应的规则，将一张表重的数据分到多张表中去。比如按照id%5的规则，将一张大表拆分成5张小表。适合具有超大表的系统。
垂直拆分：依照不同的表（或者Schema）来切分到不同的数据库（主机）之上。一般按照模块来分库。适合各业务之间耦合度非常低的系统。
6.隔离级别

read uncommit:读不加锁，写加共享锁。会产生脏读、幻读。
read commit：读加共享锁，写加排它锁，但不加间隙锁。间隙锁的主要作用是防止不可重复读，但会加大锁的范围。
repeatable read(innodb默认):读加共享锁，写加间隙排它锁。注意，Innodb对这个级别进行了特殊处理，使得这个级别能够避免幻读，但不是所有引擎都能够防止幻读！(网易面试官问)
serialization：会给整张表加锁，强一致，但是效率低。
7.innodb中的锁

MVCC(multi-Version Concurrency Control)：读不加锁，读写不冲突。适合写少读多的场景。读操作分为：快照读（返回记录的可见版本，不加锁）、当前读（记录的最新版本，加锁，保证其它记录不修改）。
LBCC(Lock-Based Concurrency Control)：
join原理Simple Nested-Loop Join：效率最低，按照join的次序，在join的属性上一个个扫描，并合并结果。
Index Nested-Loop Join：效率最高，join的属性上面有索引，根据索引来匹配。
Block Nested-Loop Join：用于没有索引的列。它会采用join buffer，将外表的值缓存到join buffer中，然后与内表进行批量比较，这样可以降低对外表的访问频率
8.galera

多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的。
同步复制，各节点间无延迟且节点宕机不会导致数据丢失。
紧密耦合，所有节点均保持相同状态，节点间无不同数据。
无需主从切换操作。
无需进行读写分离。
并发复制：从节点在APPLY数据时，支持并行执行，有更好的性能表现。
故障切换：在出现数据库故障时，因为支持多点写入，切的非常容易。
热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小。
自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致。
对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到。
9.LSM Tree，主要应用于nessDB、leveldb、hbase

核心思想的核心就是放弃部分读能力，换取写入的最大化能力。它假设假定内存足够大，因此不需要每次有数据更新就必须将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到最后多之后，再使用归并排序的方式将内存内的数据合并追加到磁盘队尾。（使用归并排序是要因为带排序树都是有序树）
LSM具有批量特性，存储延迟。B树在insert的时候可能会造成分裂，可能会造成随机读写。而LSM将多次单页随机写，变成一次多页随机写,复用了磁盘寻道时间，极大提升效率。
LSM Tree放弃磁盘读性能来换取写的顺序性。
一般会使用Bloom Filter来优化LSM。当将内存中的数据与磁盘数据合并的时候，先要判断数据是否有重复，如果不用Bloom Filter就需要在磁盘上一层层地找，而使用了之后就会降低搜索代价。
多线程
synchronized、CAS
Collections
支持高并发的数据结构，如ConcurrentHashMap
基于AQS实现的锁、信号量、计数器原理
Runnable与Callable的区别
线程池
作用
减少在创建和销毁线程上所花的时间以及系统资源的开销 。
当前任务与主线程隔离，能实现和主线程的异步执行，特别是很多可以分开重复执行的任务。
8.阻塞队列

9.threadlocal

Spring框架
IOC/DI
Core、Beans、Context、Expression Language
JDBC、ORM、OXM、JMS、Transaction
AOP
Web
Test
@Autowired原理
工厂模式
反射
自动配置@ConfigurationProperties(prefix = “hello”)：读取以hello为开头的配置，属性类使用
@Configuration：指名当前类为配置类
@EnableConfigurationProperties(Properties)：指名配置属性类
@ConditionalOnClass(Condition.class)：条件类，只有Condition.class存在，当前配置类才生效
Spring Boot在spring.factories配置了很多全限定名的配置类。
Redis
核心原理

常用数据类型String:二进制安全，可以存任何数据，比如序列化的图片。最大长度位512M.
Hash:是KV对集合，本质是String类型的KV映射，适合存储对象。
List:简单字符串链表，可以在left、right两边插入，本质是双向链表。缓冲区也是用这个实现。
Set:String类型的无序集合,内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
zset:有序集合，每个元素会关联一个double类型的score，然后根据score进行排序。注意：元素不能重复，但是score是可以重复的。使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score.
pub/sub:在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。
持久化

RDB：一种是手动执行持久化命令来持久化快照；另一种是在配置文件中配置策略，来自动持久化。持久化命令有save、bgsave两种，bgsave会调用fork命令，产生子进程来进行持久化，而父进程继续处理数据，但是持久化的快照是fork那一刻的快照，因此这种策略可能会丢失一部分数据。特点：每次都记录所有数据，恢复快，子进程不影响父进程性能。
AOF：append only file，将每条操作命令都记录到appendonly.aof文件中，但是不会立马写入硬盘，我们可以配置always（每有一个命令，都同步）、everysec（每秒同步一次）、no（没30秒同步一次）。往往everysec就够了。aof数据损失要比RDB小。特点：有序记录所有操作，数据丢失更少，会对操作做压缩优化，bgrewriteaof也会fork子进程，不影响父进程性能
事务

Transactions:不是严格的ACID的事务，但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。
Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。
KafKA
topic
broker
partition
consumer
producer
stream
存储机制
网络模型
注意：partition之间是无序的
消息队列的生产者消费者中消费者没有收到消息怎么办，消息有顺序比如1.2.3但是收到的却是1.3.2怎么办？消息发过来的过程中损坏或者出错怎么办
Spring security
拦截器栈
@PreAuthorize
@PostAuthorize
支持Expression Language
jvm原理
内存模型、垃圾收集器、CMS与G1是重点

垃圾收集算法

标记-清除(CMS)容易产生碎片，当碎片太多会提前触发Full GC
复制(年轻代基本用这个算法)会浪费一半的可能感觉
标记-整理(serial Old、Parallel Old)
Serial：采用单线程stop-the-world的方式进行收集。当内存不足时，串行GC设置停顿标识，待所有线程都进入安全点(Safepoint)时，应用线程暂停，串行GC开始工作，采用单线程方式回收空间并整理内存。串行收集器特别适合堆内存不高、单核甚至双核CPU的场合。
ParNew
Parallel Scavenge
CMS：

初始标记(stop of world)
并行标记、预清理
重新标记(stop of world)
并行清理
G1

将堆分成很多region，可以同时堆年轻代与老年代进行收集

初始标记（stop of world）:初始标记(Initial Mark)负责标记所有能被直接可达的根对象(原生栈对象、全局对象、JNI对象)
并行标记:
重新标记（stop of world）:
清理（stop of world）:
重置
gc触发条件

从年轻代分区拷贝存活对象时，无法找到可用的空闲分区，会触发Minor GC
从老年代分区转移存活对象时，无法找到可用的空闲分区，会触发Major GC
分配巨型对象时在老年代无法找到足够的连续分区，会触发Major GC
可达性分析：通过检查一块内存空间能否被root达到，来判断是否对其进行回收。
jdk不同版本新增的部分特性

jvm调优

VisualVM:JDK自带JVM可视化工具，能过对内存、gc、cpu、thread、class、变量等等信息进行可视化。
设计模式
单例双重检查
观察者模式
装饰者模式:jdk中输入输出流用到了该模式
适配器模式:jdk中Reader、writer用到了该模式
代理模式
静态代理
JDK动态代理
Cglib到动态代理
生产者消费者模式
工厂模式
项目管理与运维工具
git+Jenkins
maven
K8Spod：Pod是所有业务类型的基础，所有的容器均在Pod中运行,它是一个或多个容器的组合。每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口。Pod能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。
kubelet：kubelet负责管理pods和它们上面的容器，images镜像、volumes、etc。
ingress，用于负载均衡
docker
docker与虚拟机的区别
数据结构
平衡二叉树AVL
高度log(n)
插入时间复杂度log(n)
红黑树
插入时间复杂度log(n)
查找时间复杂度log(n)
在查找是，红黑树虽然复杂度也是log(n),但是从效率上比要略低于AVL。但是其优势在于插入元素的时候，不会像AVL那样频繁地旋转。
B+Tree：只有叶子节点存值，非叶子节点只存key和child，因此同样大小的物理页上能存放更多的节点。每一层的节点数量越多，意味着层次越少，也就意味着IO次数越少，因此非常适合数据库以及文件系统。
大根堆：采用数组存储树，是一个完全树。先插入到数组最后的位置上，然后采用上浮的思想，将该元素与比它小的父元素调换，直到parent>target，浮到root;然后将root与未排序的最后一个元素交换位置；重复以上步骤，直到所有元素都有序。插入如查找的复杂度都是log(n)。
优先队列PriorityQueue，Java中使用小根堆实现，非线程安全。
优先阻塞队列PriorityBlockQueue，线程安全。
算法
快排
时间复杂度O(nlog(n))
空间复杂度O(log(n))
堆排序
时间复杂度O(nlog(n))
空间复杂度O(1)
归并排序
时间复杂度O(nlog(n))
空间复杂度O(n)
跳表时间复杂度O(log(n))
空间复杂度O(2n)
高度O(log(n))
分布式
cap理论

可用性
一致性
分区容忍性：对网络断开的容忍度，有点像鲁棒性
拜占庭将军问题
Raft 算法

有leader、follower、candidate
同步流程

由客户端提交数据到Leader节点。
由Leader节点把数据复制到集群内所有的Follower节点。如果一次复制失败，会不断进行重试。
Follower节点们接收到复制的数据，会反馈给Leader节点。
如果Leader节点接收到超过半数的Follower反馈，表明复制成功。于是提交自己的数据，并通知客户端数据提交成功。
由Leader节点通知集群内所有的Follower节点提交数据，从而完成数据同步流程。
zookeeper
Zab（Zookeeper Atomic Broadcast）协议,有两种模式：
它们分别是：恢复模式（选主）和广播模式（同步）。
有两种算法：1. basic paxos；2. fast paxos（默认）
文件系统：zookeeper的通知机制、分布式锁、队列管理、配置管理都是基于文件系统的。
分布式锁：有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
独占锁：将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
控制时序锁：/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除。
队列管理，分为同步队列、非同步队列
数据复制的好处
容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
提高性能：让客户端本地访问就近的节点，提高用户访问速度。
5.一致性hash算法原理

微服务
Spring cloud

网关：zuul
分布式版本化配置 config
服务注册和发现：Eureka，配置时需要注意多久刷新列表一次，多久监测心跳等。
service-to-service 调用
负载均衡：Ribbon；在生成RestTemplate的bean时，通过@LoadBalanced注解可以使得RestTemplate的调用
断路器：Hystrix
监控：spring admin。在启动类上加@EnableAdminServer注解。
java web
servlet工作原理
tomcat工作原理,好文，强推
container
linux
系统结构，讲得很好，强推
硬链接与软连接
硬链接：数据节点通过引用计数的方式来对指向它的硬链接计数，当计数为0就删除。
软连接：我们可以把它看成是快捷方式，它只是记录了某个文件的硬链接的路径，如果我们把源文件删除，再重新创建一个相同名字的文件，那么软连接指向的就是新创建的文件。
虚拟文件系统(VFS)：文件系统是有很多实现的，比如ext2、ext3、FAT等等，而VFS则是存在于应用程序与文件系统中间，它封装了open、close、read、write等等操作文件系统的接口，为应用程序屏蔽掉不同文件系统之间的差异。
VFS数据结构
其它
bitmap，大文件交集
Elasticsearch索引原理
从内存到屏幕经历了啥
高并发场景的限流，你怎么来确定限流限多少，模拟场景和实际场景有区别怎么解决，
百度面试
说一下redis与kafka，redis持久化策略
git中rebase与merge区别
docker底层原理，依赖操作系统的什么
ls -l | grep xxx的执行过程，尽可能的细，是多进程还是单进程？
两个有序数组求中位数
算法 3Sum、中序遍历非递归实现、循环打印矩阵
final、finally、finanize
jvm内存模型
垃圾回收器
Spring特点介绍下
Synchronize与ReentrantLock的区别、使用场景
CAS使用场景
聊了下git+jekins+K8S+docker实现自动化部署
innodb原理，使用场景，与MYISAM在场景上的区别
weakReference、softReference等
Hbase的原理，LSM Tree
Linux中，哪种进程可以使用管道
美团
权限模型
介绍下线程池，阻塞队列的用法，无界队列真的无界吗？
说一下redis
kafka存储模型与网络模型
zookeeper与redis实现分布式锁
乐观锁与悲观锁
算法：有n个人，给你ai与aj的身高关系，如ai比aj高，进行身高排序，如果条件不满足，则输出“不满足”
Spring boot的特性

---

第三部分：

Web前端指网站业务逻辑之前的部分，包括：

1.浏览器加载

2.网站视图模型

3.图片服务

4.CDN服务等

主要优化手段有优化浏览器访问，使用反向代理，CDN等。

1.浏览器访问优化

(1)减少http请求

HTTP协议是无状态的应用层协议，意味着每次HTTP请求都需要简历通信链路，进行数据传输，而在服务器端，每个HTTP都需要启动独立的线程去处理，这些通信和服务的开销都很昂贵，减少HTTP请求的数目可有效提高访问性能。

减少HTTP请求的主要手段是:

合并CSS，以及压缩CSS大小
合并JavaScript，以及压缩JS大小
合并图片
将浏览器一次访问需要的JavaScript,CSS合并成一个文件，这样浏览器就只需要一次请求。多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标点击操作，构造不同的URL。

(2)使用浏览器缓存

对一个网站而言，CSS,JavaScript,Logo,图标等这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次HTTP请求都需要的，如果将这些文件缓存在浏览器中，可以极好地改善性能。通过设置HTTP头中Cache-Control和Expires属性，可设定浏览器缓存，缓存时间可以是数天甚至是几个月。有时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况可以通过改变文件名实现，比如一般会在JavaScript后面加上一个版本号，使浏览器刷新修改的文件。

(3)启用压缩

在服务器端对文件进行压缩，在浏览器端对文件解压缩，可有效较少通信传输的数据量。文本文件的压缩效率科大80%以上。

(4)CSS放在页面最上面，JavaScript放在页面最下面

浏览器会在下载完全部CSS之后对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS。JS则想法，浏览器在加载JS后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此JS最好放在页面最下面。

(5)减少Cookie传输

一方面，Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输，因此哪些数据需要写入Cookie需要慎重考虑，尽量减少Cookie中传输的数据量。另一方面，对于某些静态资源的访问，如CSS,JS等，发送Cookie没有意义，可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie，减少Cookie传输的次数。

阿里P8架构师谈：Web前端、应用服务器、数据库SQL等性能优化总结
2.CDN加速

CDN(Content Distribute Network,内存分发网络)的本质上仍然是一个缓存，而且将数据缓存在离用户最近的地方，是用户以最快速度获取数据，即所谓网络访问第一跳。

CDN一般缓存的是静态资源，如图片，文件，CSS，Script脚本，静态网页等，但是这些文件访问频率很高，将其缓存在CDN可极大改善网页的打开速度。

3.反向代理

传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网络攻击之间建立了一个屏障。

除了安全功能，代理服务器也可以通过配置缓存功能加速Web请求，当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器返回，加速Web请求响应速度，减轻服务器负载要。

应用服务器性能优化
应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开发最复杂，变化最多的地方，优化手段主要有缓存、集群和异步等。

网站性能优化第一定律：优先考虑使用缓存优化性能。

缓存的本质是一个内存Hash表，网站应用中，数据缓存以一对Key,Value的形式存储在内存Hash表中。缓存主要用来存放那些读写比很高、很少变化的数据。

二八定律：80%的访问落在20%的数据上

使用缓存需要注意的问题：

把频繁修改的数据放入缓存。容易出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效的情形，徒增系统负担。一般来说，数据的读写比在2:1以上，缓存才有意义。
没有热点的访问。 缓存使用的内存资源非常宝贵，只能将最新访问的数据缓存起来，而把历史数据清理出缓存。即缓存资源应该留给20%的热点数据。
数据不一致与脏读。 一般会对缓存设置失效时间，超过失效时间，就要从数据库重新加载。因此应用要忍受一定时间的数据不一致。另一种策略是数据更新时立即更新缓存，不过这也会带来更多的系统开销和事务一致性的问题。
缓存可用性。 业务发展到一定阶段时，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务器崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。 解决方式：1、缓存热备（当某台服务器宕机时，将缓存访问切换到热备服务器上。）；2、缓存服务器集群。
缓存预热。 缓存中存放的是热点数据，热点数据是缓存系统用LRU对不断访问的数据筛选出来的，这个过程需要较长的时间。新启动的缓存系统没有任何数据，此时系统的性能和数据库负载都不太好。因此可以选择在启动缓存是就把热点数据预加载好。
缓存穿透。 因为不恰当的业务或恶意攻击，持续高并发地访问某一个不存在的数据，如果缓存不保存该数据，就会有大量的请求压力落在数据库上。简单的解决方式是把请求的不存在的数据也放进缓存，其value是null。
对应可以考虑的分布式缓存有memcached、redis，降低对数据库的读操作。

数据库SQL性能优化
最后就是考虑数据库端的性能优化，如果访问量巨大，除了sql优化外，还会涉及到分库分表、读写分离、利用数据库中间件来解决(下面架构师系列有讲)，这里就不再重复。

1.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null
3.应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。

5.in和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)
对于连续的数值，能用 between就不要用 in 了：

select id from t where num between 1 and 3
6.对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高。

7.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。

8.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连 接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

9.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

10.尽量避免大事务操作，提高系统并发能力。

---

第四部分：

默认也推荐使用netty框架，还有mina。

2、默认是阻塞的，可以异步调用，没有返回值的可以这么做。

3、推荐使用zookeeper注册中心，还有redis等不推荐。

4、默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。

5、服务失效踢出基于zookeeper的临时节点原理。

6、采用多版本开发，不影响旧版本。

7、可以结合zipkin实现分布式服务追踪。

8、核心配置有 dubbo:service/ dubbo:reference/ dubbo:protocol/ dubbo:registry/ dubbo:application/ dubbo:provider/ dubbo:consumer/ dubbo:method/

9、默认使用dubbo协议。

10、可以直连，修改配置即可，也可以通过telnet直接某个服务。

11、流程图见dubbo.io。

12、读操作建议使用Failover失败自动切换，默认重试两次其他服务器。写操作建议使用Failfast快速失败，发一次调用失败就立即报错。

13、使用过程中的问题可以百度

14、dubbox是当当网基于dubbo上做了一些扩展，如加了服务可restful调用，更新了开源组件等。

15、别的还有spring的spring cloud，facebook的thrift，twitter的finagle等。

Zookeeper面试集锦
1、zookeeper是一个开源的分布式协调服务框架。

2、应用场景：分布式通知/协调、负载均衡、配置中心、分布式锁、分布式队列等。

3、使用ZAB协议。

4、Paxos算法看最后文章推荐的书。

5、选举算法及流程看最后文章推荐的书。

6、节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。

7、不是永久的，一次性的，需要借助第三方工具实现重复注册。

8、部署模式：单机模式、伪集群模式、集群模式。

9、集群角色：leader、foller、observer。

10、集群规则为2N+1台，N>0，即3台。

11、集群需要一半以上的机器可用，所以，3台挂掉1台还能工作，2台不能。

12、3.5版本开始支持动态扩容。

13、java客户端：zk自带的zkclient及Apache开源的Curator。

14、chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。

15、常用命令：ls get set create delete等。

---

第五部分：

数据结构与算法：最常见的各种排序，最好能手写

Java高级：JVM内存结构、垃圾回收器、回收算法、GC、并发编程相关(多线程、线程池等)、NIO/BIO、各种集合类的比较优劣势(底层数据结构也要掌握，特别是扩容等)等。

性能优化、设计模式、UML的掌握

Spring框架：重点掌握(BAT每次必问)

分布式相关：Redis缓存、一致Hash算法、分布式存储、负载均衡等。

微服务以及Docker容器等。

阿里面试总结
阿里的面试特别喜欢面试技术原理，特别是

多线程

NIO

异步消息框架

分布式相关的缓存算法等

JVM的加载过程和原理

回收算法

以及具体使用过的框架，会问部分参数检验你是否熟用

---

第六部分：

ArrayList和linkedlist区别。ArrayList是否会越界。
ArrayList和hashset有何区别。hashset存的数是有序的么。
volatile和synchronized区别
多态的原理
数据库引擎Innodb和myisam区别
Redis的数据结构
Redis是基于内存的么
Redis的list zset的底层实现
http和https的区别，tcp握手过程
jvm垃圾回收算法手写冒泡
手写单例包括多线程下
Java线程间怎么实现同步，notify()与notifyAll()的区别
数据库的悲观锁和乐观锁应用场景。
排序算法的复杂度，快速排序非递归实现。
海量数据过滤，黑名单过滤一个url。
二面：
list set map 底层使用什么实现的有哪些典型实现
hashmap扩容是怎么扩容的，为什么是2的幂
concurrenthashmap为什么线程安全，采用了什么措施应对高并发
线程池的参数有什么意义
Springmvc请求流程
Spring IOC，autowired如何实现
Spring boot
SpringClound的基本架构设计
Dubbo和SpringClound的区别在哪里，优劣势
说说一致性Hash算法
三面：
分布式架构设计哪方面比较熟悉
讲讲你对CDN的了解，与分布式缓存和本地缓存的区别
多线程和高并发有什么区别
高并发下有哪些常用的技术解决方案，举三个高并发场景设计例子
说一个你对JVM优化的实际案例，包括实际步骤和方法
Docker有使用过和了解吗？Docker和JVM的区别是什么？
Docker的基本架构和使用场景？
负载均衡有接触过哪些开源框架，优劣势是什么？
数据库分库分表需要怎样来实现？
数据库端的常用优化策略？
如果让你来设计秒杀系统，你的设计思路是什么，为什么要这样设计？

面试总结：
java的基础知识点，主要围绕在集合类和多线程等：ArrayList、LinkedList、HashSet、HashpMap的数据结果，以及如何扩容、以及ConcurrentHashMap相关的多线程安全等。
JVM的内存分配、几个常见的垃圾回收算法以及原理、还有对应的JVM优化参数需要牢记。
网络：TCP的三次握手等网络都必问，重点掌握网络协议。
Redis：作为分布式缓存的主力，基本也是BAT每次必考，重点是Redis的数据结构、内存、算法、持久化，以及与别的缓存memcached的优劣势。
多线程：状态流转、多线程的实现，以及与高并发的区别等。
Spring框架问得是最多的，BAT非常喜欢问，重点掌握。
最后就是分布式架构设计
常用的分布式架构设计方案：单点登录、分布式缓存、存储、消息的选型，还有就是数据库端的优化方案(需要提前了解)。
最好能提前了解深入一个类似秒杀这样的项目，如果面试官问到类似的项目，你能把设计思路讲出来，这对你的面试结果是很大的加分项。

---

第七部分：

Memcached是一个开源的，高性能的内存绶存软件，从名称上看Mem就是内存的意思，而Cache就是缓存的意思。Memcached的作用：通过在事先规划好的内存空间中临时绶存数据库中的各类数据，以达到减少业务对数据库的直接高并发访问，从而达到提升数据库的访问性能，加速网站集群动态应用服务的能力。

Memcached服务在企业集群架构中有哪些应用场景？

一、作为数据库的前端缓存应用
a、完整缓存（易），静态缓存
例如：商品分类（京东），以及商品信息，可事先放在内存里，然后再对外提供数据访问，这种先放到内存，我们称之为预热，（先把数据存缓存中），用户访问时可以只读取memcached缓存，不读取数据库了。
b、执点缓存（难）
需要前端web程序配合，只缓存热点的数据，即缓存经常被访问的数据。
先预热数据库里的基础数据，然后在动态更新，选读取缓存，如果缓存里没有对应的数据，程序再去读取数据库，然后程序把读取的新数据放入缓存存储。

特殊说明 ：

1、如果碰到电商秒杀等高并发的业务，一定要事先预热，或者其它思想实现，例如：称杀只是获取资格，而不是瞬间秒杀到手商品。
那么什么是获取资格？

就是在数据库中，把0标成1.就有资格啦。再慢慢的去领取商品订单。因为秒杀过程太长会占用服务器资源。

2、如果数据更新，同时触发缓存更新，防止给用户过期数据。

c、对于持久化缓存存储系统，例如：redis，可以替代一部分数据库的存储，一些简单的数据业务，投票，统计，好友关注，商品分类等。nosql= not only sql

二、作业集群的session会话共享存储。

3、Memcached服务在不同企业业务应用场景中的工作流程
a、当web程序需要访问后端数据库获取数据时会优先访问Memcached内存缓存，如果缓存中有数据就直接获取返回前端服务及用户，如果没有数据（没有命中），在由程序请求后端的数据库服务器，获取到对应的数据后，除了返回给前端服务及用户数据外，还会把数据放到Memcached内存中进行缓存，等待下次请求被访问，Memcache内存始终是数据库的挡箭牌，从而大大的减轻数据库的访问压力，提高整个网站架构的响应速度，提升了用户体验。

b、当程序更新，修改或删除数据库中已有的数据时，会同时发送请求通知Memcached已经缓存的同一个ID内容的旧数据失效，从而保证Memcache中数据和数据库中的数据一致。

如果在高并发场合，除了通知Memcached过程的缓存失效外，还会通过相关机制，使得在用户访问新数据前，通过程序预先把更新过的数据推送到memcache中缓存起来，这样可以减少数据库的访问压力，提升Memcached中缓存命中率。

c、数据库插件可以再写入更新数据库后，自动抛给MC缓存起来，自身不Cache.

Memcached服务分布式集群如何实现？
特殊说明：Memcached集群和web服务集群是不一样的，所有Memcached的数据总和才是数据库的数据。每台Memcached都是部分数据。
（一台memcached的数据，就是一部分mysql数据库的数据）

a、程序端实现
程序加载所有mc的ip列表，通过对key做hash (一致性哈希算法)
例如：web1 (key)===>对应A,B,C,D,E,F,G……若干台服务器。（通过哈希算法实现）

b、负载均衡器
通过对key做hash (一致性哈希算法)

一致哈希算法的目的是不但保证每个对象只请求一个对应的服务器，而且当节点宕机，缓存服务器的更新重新分配比例降到最低。

Memcached服务特点及工作原理是什么？

a、完全基于内存缓存的
b、节点之间相互独立
c、C/S模式架构，C语言编写，总共2000行代码。
d、异步Ｉ/O 模型，使用libevent作为事件通知机制。
e、被缓存的数据以key/value键值对形式存在的。
f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失。
g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用LRU算法删除过期的缓存数据。
h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是在访问的时候查看key的时间戳,判断是否过期。
j、memcache会对设定的内存进行分块，再把块分组，然后再提供服务。

简述Memcached内存管理机制原理？
早期的Memcached内存管理方式是通过malloc的分配的内存，使用完后通过free来回收内存，这种方式容易产生内存碎片，并降低操作系统对内存的管理效率。加重操作系统内存管理器的负担，最坏的情况下，会导致操作系统比memcached进程本身还慢，为了解决这个问题，Slab Allocation内存分配机制就延生了。

现在Memcached利用Slab Allocation机制来分配和管理内存。

Slab
Allocation机制原理是按照预先规定的大小，将分配给memcached的内存分割成特定长度的内存块（chunk)，再把尺寸相同的内存块，分成组
（chunks slab class),这些内存块不会释放，可以重复利用。

而且，slab allocator还有重复使用已分配的内存的目的。 也就是说，分配到的内存不会释放，而是重复利用。

Slab Allocation的主要术语

Page

分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。

Chunk

用于缓存记录的内存空间。

Slab
Class

特定大小的chunk的组。

集群架构方面的问题

memcached是怎么工作的？
Memcached的神奇来自两阶段哈希（two-stage hash）。Memcached就像一个巨大的、存储了很多<key,value>对的哈希表。通过key，可以存储或查询任意的数据。

客户端可以把数据存储在多台memcached上。当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；客户端将请求发送给选中的节点，然后memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）。

memcached最大的优势是什么？
Memcached最大的好处就是它带来了极佳的水平可扩展性，特别是在一个巨大的系统中。由于客户端自己做了一次哈希，那么我们很容易增加大量memcached到集群中。memcached之间没有相互通信，因此不会增加 memcached的负载；没有多播协议，不会网络通信量爆炸（implode）。memcached的集群很好用。内存不够了？增加几台 memcached吧；CPU不够用了？再增加几台吧；有多余的内存？在增加几台吧，不要浪费了。

基于memcached的基本原则，可以相当轻松地构建出不同类型的缓存架构。除了这篇FAQ，在其他地方很容易找到详细资料的。

memcached和MySQL的query
cache相比，有什么优缺点？
把memcached引入应用中，还是需要不少工作量的。MySQL有个使用方便的query cache，可以自动地缓存SQL查询的结果，被缓存的SQL查询可以被反复地快速执行。Memcached与之相比，怎么样呢？MySQL的query cache是集中式的，连接到该query cache的MySQL服务器都会受益。

• 当您修改表时，MySQL的query cache会立刻被刷新（flush）。存储一个memcached item只需要很少的时间，但是当写操作很频繁时，MySQL的query cache会经常让所有缓存数据都失效。

• 在多核CPU上，MySQL的query cache会遇到扩展问题（scalability issues）。在多核CPU上，query cache会增加一个全局锁（global lock）, 由于需要刷新更多的缓存数据，速度会变得更慢。

• 在 MySQL的query cache中，我们是不能存储任意的数据的（只能是SQL查询结果）。而利用memcached，我们可以搭建出各种高效的缓存。比如，可以执行多个独立的查询，构建出一个用户对象（user object），然后将用户对象缓存到memcached中。而query cache是SQL语句级别的，不可能做到这一点。在小的网站中，query cache会有所帮助，但随着网站规模的增加，query cache的弊将大于利。

• query cache能够利用的内存容量受到MySQL服务器空闲内存空间的限制。给数据库服务器增加更多的内存来缓存数据，固然是很好的。但是，有了memcached，只要您有空闲的内存，都可以用来增加memcached集群的规模，然后您就可以缓存更多的数据。

memcached和服务器的local cache（比如PHP的APC、mmap文件等）相比，有什么优缺点？
首先，local cache有许多与上面(query cache)相同的问题。local cache能够利用的内存容量受到（单台）服务器空闲内存空间的限制。不过，local
cache有一点比memcached和query cache都要好，那就是它不但可以存储任意的数据，而且没有网络存取的延迟。

• local cache的数据查询更快。考虑把highly common的数据放在local cache中吧。如果每个页面都需要加载一些数量较少的数据，考虑把它们放在local
  cached吧。

• local cache缺少集体失效（group
  invalidation）的特性。在memcached集群中，删除或更新一个key会让所有的观察者觉察到。但是在local cache中, 我们只能通知所有的服务器刷新cache（很慢，不具扩展性），或者仅仅依赖缓存超时失效机制。

• local cache面临着严重的内存限制，这一点上面已经提到。

memcached的cache机制是怎样的？
Memcached主要的cache机制是LRU（最近最少用）算法+超时失效。当您存数据到memcached中，可以指定该数据在缓存中可以呆多久Which is forever,
or some time in the future。如果memcached的内存不够用了，过期的slabs会优先被替换，接着就轮到最老的未被使用的slabs。

memcached如何实现冗余机制？
不实现！我们对这个问题感到很惊讶。Memcached应该是应用的缓存层。它的设计本身就不带有任何冗余机制。如果一个memcached节点失去了所有数据，您应该可以从数据源（比如数据库）再次获取到数据。您应该特别注意，您的应用应该可以容忍节点的失效。不要写一些糟糕的查询代码，寄希望于 memcached来保证一切！如果您担心节点失效会大大加重数据库的负担，那么您可以采取一些办法。比如您可以增加更多的节点（来减少丢失一个节点的影响），热备节点（在其他节点down了的时候接管IP），等等。

memcached如何处理容错的？

不处理！? 在memcached节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方案供您选择：

• 忽略它！ 在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带来的影响。

• 把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上。

• 启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱（hashing chaos）。

• 如果希望添加和移除节点，而不影响原先的哈希结果，可以使用一致性哈希算法（consistent hashing）。您可以百度一下一致性哈希算法。支持一致性哈希的客户端已经很成熟，而且被广泛使用。去尝试一下吧！

• 两次哈希（reshing）。当客户端存取数据时，如果发现一个节点down了，就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注意的时，客户端并没有把down的节点从节点列表中移除，下次还是有可能先哈希到它）。如果某个节点时好时坏，两次哈希的方法就有风险了，好的节点和坏的节点上都可能存在脏数据（stale data）。

如何将memcached中item批量导入导出？
您不应该这样做！Memcached是一个非阻塞的服务器。任何可能导致memcached暂停或瞬时拒绝服务的操作都应该值得深思熟虑。向 memcached中批量导入数据往往不是您真正想要的！想象看，如果缓存数据在导出导入之间发生了变化，您就需要处理脏数据了；

如果缓存数据在导出导入之间过期了，您又怎么处理这些数据呢？
因此，批量导出导入数据并不像您想象中的那么有用。不过在一个场景倒是很有用。如果您有大量的从不变化的数据，并且希望缓存很快热（warm）起来，批量导入缓存数据是很有帮助的。虽然这个场景并不典型，但却经常发生，因此我们会考虑在将来实现批量导出导入的功能。

如果一个memcached节点down了让您很痛苦，那么您还会陷入其他很多麻烦。您的系统太脆弱了。您需要做一些优化工作。比如处理”惊群”问题（比如 memcached节点都失效了，反复的查询让您的数据库不堪重负…这个问题在FAQ的其他提到过），或者优化不好的查询。记住，Memcached 并不是您逃避优化查询的借口。

memcached是如何做身份验证的？
没有身份认证机制！memcached是运行在应用下层的软件（身份验证应该是应用上层的职责）。memcached的客户端和服务器端之所以是轻量级的，部分原因就是完全没有实现身份验证机制。这样，memcached可以很快地创建新连接，服务器端也无需任何配置。

如果您希望限制访问，您可以使用防火墙，或者让memcached监听unix domain socket。

memcached的多线程是什么？如何使用它们？
线程就是定律（threads rule）！在Steven Grimm和Facebook的努力下，memcached 1.2及更高版本拥有了多线程模式。多线程模式允许memcached能够充分利用多个CPU，并在CPU之间共享所有的缓存数据。memcached使用一种简单的锁机制来保证数据更新操作的互斥。相比在同一个物理机器上运行多个memcached实例，这种方式能够更有效地处理multi gets。

如果您的系统负载并不重，也许您不需要启用多线程工作模式。如果您在运行一个拥有大规模硬件的、庞大的网站，您将会看到多线程的好处。

简单地总结一下：命令解析（memcached在这里花了大部分时间）可以运行在多线程模式下。memcached内部对数据的操作是基于很多全局锁的（因此这部分工作不是多线程的）。未来对多线程模式的改进，将移除大量的全局锁，提高memcached在负载极高的场景下的性能。

memcached能接受的key的最大长度是多少？
key的最大长度是250个字符。需要注意的是，250是memcached服务器端内部的限制，如果您使用的客户端支持”key的前缀”或类似特性，那么key（前缀+原始key）的最大长度是可以超过250个字符的。我们推荐使用使用较短的key，因为可以节省内存和带宽。

memcached对item的过期时间有什么限制？

过期时间最大可以达到30天。memcached把传入的过期时间（时间段）解释成时间点后，一旦到了这个时间点，memcached就把item置为失效状态。这是一个简单但obscure的机制。

memcached最大能存储多大的单个item？
1MB。如果你的数据大于1MB，可以考虑在客户端压缩或拆分到多个key中。

为什么单个item的大小被限制在1M byte之内？

啊…这是一个大家经常问的问题！

简单的回答：因为内存分配器的算法就是这样的。

详细的回答：Memcached的内存存储引擎（引擎将来可插拔…），使用slabs来管理内存。内存被分成大小不等的slabs chunks（先分成大小相等的slabs，然后每个slab被分成大小相等chunks，不同slab的chunk大小是不相等的）。chunk的大小依次从一个最小数开始，按某个因子增长，直到达到最大的可能值。

memcached能够更有效地使用内存吗？
Memcache客户端仅根据哈希算法来决定将某个key存储在哪个节点上，而不考虑节点的内存大小。因此，您可以在不同的节点上使用大小不等的缓存。但是一般都是这样做的：拥有较多内存的节点上可以运行多个memcached实例，每个实例使用的内存跟其他节点上的实例相同。

什么是二进制协议，我该关注吗？
关于二进制最好的信息当然是二进制协议规范：

二进制协议尝试为端提供一个更有效的、可靠的协议，减少客户端/服务器端因处理协议而产生的CPU时间。

根据Facebook的测试，解析ASCII协议是memcached中消耗CPU时间最多的环节。所以，我们为什么不改进ASCII协议呢？

memcached的内存分配器是如何工作的？为什么不适用malloc/free！？为何要使用slabs？

实际上，这是一个编译时选项。默认会使用内部的slab分配器。您确实确实应该使用内建的slab分配器。最早的时候，memcached只使用 malloc/free来管理内存。然而，这种方式不能与OS的内存管理以前很好地工作。反复地malloc/free造成了内存碎片，OS最终花费大量的时间去查找连续的内存块来满足malloc的请求，而不是运行memcached进程。如果您不同意，当然可以使用malloc！只是不要在邮件列表中抱怨啊:)

slab分配器就是为了解决这个问题而生的。内存被分配并划分成chunks，一直被重复使用。因为内存被划分成大小不等的slabs，如果item 的大小与被选择存放它的slab不是很合适的话，就会浪费一些内存。Steven Grimm正在这方面已经做出了有效的改进。

memcached是原子的吗？
所有的被发送到memcached的单个命令是完全原子的。如果您针对同一份数据同时发送了一个set命令和一个get命令，它们不会影响对方。它们将被串行化、先后执行。即使在多线程模式，所有的命令都是原子的，除非程序有bug:)

命令序列不是原子的。如果您通过get命令获取了一个item，修改了它，然后想把它set回memcached，我们不保证这个item没有被其他进程（process，未必是操作系统中的进程）操作过。在并发的情况下，您也可能覆写了一个被其他进程set的item。

memcached 1.2.5以及更高版本，提供了gets和cas命令，它们可以解决上面的问题。如果您使用gets命令查询某个key的item，memcached会给您返回该item当前值的唯一标识。如果您覆写了这个item并想把它写回到memcached中，您可以通过cas命令把那个唯一标识一起发送给 memcached。如果该item存放在memcached中的唯一标识与您提供的一致，您的写操作将会成功。如果另一个进程在这期间也修改了这个 item，那么该item存放在memcached中的唯一标识将会改变，您的写操作就会失败

如何实现集群中的session共享存储？
Session是运行在一台服务器上的，所有的访问都会到达我们的唯一服务器上，这样我们可以根据客户端传来的sessionID，来获取session，或在对应Session不存在的情况下（session 生命周期到了/用户第一次登录），创建一个新的Session；但是，如果我们在集群环境下，假设我们有两台服务器A，B，用户的请求会由Nginx服务器进行转发（别的方案也是同理），用户登录时，Nginx将请求转发至服务器A上，A创建了新的session，并将SessionID返回给客户端，用户在浏览其他页面时，客户端验证登录状态，Nginx将请求转发至服务器B，由于B上并没有对应客户端发来sessionId的session，所以会重新创建一个新的session，并且再将这个新的sessionID返回给客户端，这样，我们可以想象一下，用户每一次操作都有1/2的概率进行再次的登录，这样不仅对用户体验特别差，还会让服务器上的session激增，加大服务器的运行压力。

为了解决集群环境下的seesion共享问题，共有4种解决方案：

1.粘性session

粘性session是指Ngnix每次都将同一用户的所有请求转发至同一台服务器上，即将用户与服务器绑定。

2.服务器session复制

即每次session发生变化时，创建或者修改，就广播给所有集群中的服务器，使所有的服务器上的session相同。

3.session共享

缓存session，使用redis， memcached。

4.session持久化

将session存储至数据库中，像操作数据一样才做session。

memcached与redis的区别？
1、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。而memcache只支持简单数据类型，需要客户端自己处理复杂对象

2、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用（PS：持久化在rdb、aof）。

3、由于Memcache没有持久化机制，因此宕机所有缓存数据失效。Redis配置为持久化，宕机重启后，将自动加载宕机时刻的数据到缓存系统中。具有更好的灾备机制。

4、Memcache可以使用Magent在客户端进行一致性hash做分布式。Redis支持在服务器端做分布式（PS:Twemproxy/Codis/Redis-cluster多种分布式实现方式）

5、Memcached的简单限制就是键（key）和Value的限制。最大键长为250个字符。可以接受的储存数据不能超过1MB（可修改配置文件变大），因为这是典型slab 的最大值，不适合虚拟机使用。而Redis的Key长度支持到512k。

6、Redis使用的是单线程模型，保证了数据按顺序提交。Memcache需要使用cas保证数据一致性。CAS（Check and Set）是一个确保并发一致性的机制，属于“乐观锁”范畴；原理很简单：拿版本号，操作，对比版本号，如果一致就操作，不一致就放弃任何操作

cpu利用。由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更 高。而在100k以上的数据中，Memcached性能要高于Redis 。

7、memcache内存管理：使用Slab Allocation。原理相当简单，预先分配一系列大小固定的组，然后根据数据大小选择最合适的块存储。避免了内存碎片。（缺点：不能变长，浪费了一定空间）memcached默认情况下下一个slab的最大值为前一个的1.25倍。

8、redis内存管理： Redis通过定义一个数组来记录所有的内存分配情况， Redis采用的是包装的malloc/free，相较于Memcached的内存 管理方法来说，要简单很多。由于malloc 首先以链表的方式搜索已管理的内存中可用的空间分配，导致内存碎片比较多

---

第八部分：

1.并发工具类

提供了比synchronized更加高级的各种同步结构：包括CountDownLatch、CyclicBarrier、Semaphore等，可以实现更加丰富的多线程操作。

2.并发容器

提供各种线程安全的容器：最常见的ConcurrentHashMap、有序的ConcurrentSkipListMap,实现线程安全的动态数组CopyOnWriteArrayList等。

3.并发队列

各种BlockingQueue的实现：常用的ArrayBlockingQueue、SynchorousQueue或针对特定场景的PriorityBlockingQueue。

4.Executor框架

可以创建各种不同类型的线程池，调度任务运行等，绝大部分情况下，不再需要自己从头实现线程池和任务调度器。

常用的并发容器
高并发编程系列：4大并发工具类的功能、原理、以及应用场景
1.ConcurrentHashMap

经常使用的并发容器，JDK 1.7和1.8的底层数据结构发生了变化(后续文章会详解)，这里可以建议学习顺序如下：从Java7 HashMap -> Java7 ConcurrentHashMap -> Java8 HashMap -> Java8 ConcurrentHashMap，这样可以更好的掌握这个并发容器，毕竟都是从HashMap进化而来。

2.ConcurrentSkipListMap

在乎顺序，需要对数据进行非常频繁的修改

3.CopyOnWrite容器

CopyOnWrite容器即写时复制的容器。从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,CopyOnWriteArrayList和CopyOnWriteArraySet。

4.各种并发队列的实现

如各种BlockedQueue实现，比较典型的ArrayBlockingQueue、SynchorousQueue。

详情请看：高并发编程系列：并发容器的原理，7大并发容器详解、及使用场景

高并发编程系列：4大并发工具类的功能、原理、以及应用场景
常用的并发工具类
高并发编程系列：4大并发工具类的功能、原理、以及应用场景
1.CountDownLatch

功能

CountDownLatch是一个同步的辅助类，允许一个或多个线程，等待其他一组线程完成操作，再继续执行。

原理：

CountDownLatch是通过一个计数器来实现的，计数器的初始值为需要等待线程的数量。
eg：CountDownLatch c = new CountDownLatch(10); // 等待线程的数量为10

主线程调用CountDownLatch的await()方法会阻塞当前线程(即:主线程在闭锁上等待)，直到计数器的值为0。
当一个工作线程完成了自己的任务后，调用CountDownLatch的countDown()方法，计数器的值就会减1。
当计数器值为0时，说明所有的工作线程都执行完了，此时，在闭锁上等待的主线程就可以恢复执行任务。
应用场景

倒数计时器

例如：一种典型的场景就是火箭发射。在火箭发射前，为了保证万无一失，往往还要进行各项设备、仪器的检查。 只有等所有检查完毕后，引擎才能点火。这种场景就非常适合使用CountDownLatch。

它可以使得点火线程，等待所有检查线程全部完工后，再执行

使用方式

static final CountDownLatch end = new CountDownLatch(10);
end.countDown();
end.await();
示意图：

高并发编程系列：4大并发工具类的功能、原理、以及应用场景
2.CyclicBarrier

功能:

CyclicBarrier的字面意思是可循环使用（Cyclic）的屏障（Barrier）。它要做的事情是，让一组线程到达一个屏障（也可以叫同步点）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。

和CountDownLatch相似，也是等待某些线程都做完以后再执行。

与CountDownLatch区别

在于这个计数器可以反复使用。比如，假设我们将计数器设置为10。那么凑齐第一批1 0个线程后，计数器就会归零，然后接着凑齐下一批10个线程。

原理：

1)CyclicBarrier是通过一个计数器来实现的，计数器的初始值为需要等待线程的数量。eg：CyclicBarrier c = new CyclicBarrier(2); // 等待线程的数量为2

2)每个线程调用CyclicBarrier的await()方法，使自己进入等待状态。

3)当所有的线程都调用了CyclicBarrier的await()方法后，所有的线程停止等待，继续运行。

使用方式：

public CyclicBarrier(int parties, Runnable barrierAction)
barrierAction就是当计数器一次计数完成后，系统会执行的动作
await()
示意图：

高并发编程系列：4大并发工具类的功能、原理、以及应用场景
3.信号量Semaphore

功能：Java提供了经典信号量Semaphore的实现，它通过控制一定数量的许可（permit）的方式，来达到限制通用资源访问的目的。例如：控制并发的线程数。

原理：

1)Semaphore是通过一个计数器(记录许可证的数量)来实现的，计数器的初始值为需要等待线程的数量。

eg：Semaphore s = new Semaphore(10); // 线程最大的并发数为10

2)线程通过acquire()方法获取许可证(计数器的值减1)，只有获取到许可证才可以继续执行下去，否则阻塞当前线程。

3)线程通过release()方法归还许可证(计数器的值加1)。

说明：使用tryAcquire()方法可以立即得到执行的结果：尝试获取一个许可证，若获取成功，则立即返回true，若获取失败，则立即返回false。

应用场景：

Semaphore可以用于做流量控制，特别是公用资源有限的应用场景，比如数据库连接。

举一个场景：例如在车站、机场等出租车时，当很多空出租车就位时，为防止过度拥挤，调度员指挥排队等待坐车的队伍一次进来5个人上车，等这5个人坐车出发，再放进去下一批。这和Semaphore的工作原理有些类似。

4.交换者Exchanger

功能：Exchanger（交换者）是一个用于线程间协作的工具类。Exchanger用于进行线程间的数据交换。它提供一个同步点，在这个同步点两个线程可以交换彼此的数据。这两个线程通过exchange方法交换数据，
如果第一个线程先执行exchange方法，它会一直等待第二个线程也执行exchange，当两个线程都到达同步点时，这两个线程就可以交换数据，将本线程生产出来的数据传递给对方。

原理：

1)线程A调用public V exchange(V dataA)方法，线程A到达同步点，并且在线程B到达同步点前一直等待。

2)线程B调用public V exchange(V dataB)方法，线程B到达同步点。

3)线程A与线程B都达到同步点时，线程将自己的数据传递给对方，两个线程完成了数据的交换了。

Exchanger的应用场景

Exchanger可以用于校对工作的场景。

---

第九部分：

Redis相比memcached有哪些优势？
(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

Redis支持哪几种数据类型？
String、List、Set、Sorted Set、hashes

Redis集群方案应该怎么做？都有哪些方案？
1.twemproxy，大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选。 问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。

Redis回收使用的是什么算法？
LRU算法

为什么要做Redis分区？
分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

Redis的内存占用情况怎么样？
给你举个例子： 100万个键值对（键是0到999999值是字符串“hello
world”）在我的32位的Mac笔记本上 用了100MB。同样的数据放到一个key里只需要16MB， 这是因为键值有一个很大的开销。 在Memcached上执行也是类似的结果，但是相对Redis的开销要小一点点，因为Redis会记录类型信息引用计数等等。

Memcached服务特点及工作原理是什么？
a、完全基于内存缓存的

b、节点之间相互独立

c、C/S模式架构，C语言编写，总共2000行代码。

d、异步Ｉ/O 模型，使用libevent作为事件通知机制。

e、被缓存的数据以key/value键值对形式存在的。

f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会丢失。

g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用LRU算法删除过期的缓存数据。

h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不会监控过期，而是在访问的时候查看key的时间戳,判断是否过期。

j、memcache会对设定的内存进行分块，再把块分组，然后再提供服务。

如何实现集群中的session共享存储？
Session是运行在一台服务器上的，所有的访问都会到达我们的唯一服务器上，这样我们可以根据客户端传来的sessionID，来获取session，或在对应Session不存在的情况下（session 生命周期到了/用户第一次登录），创建一个新的Session；但是，如果我们在集群环境下，假设我们有两台服务器A，B，用户的请求会由Nginx服务器进行转发（别的方案也是同理），用户登录时，Nginx将请求转发至服务器A上，A创建了新的session，并将SessionID返回给客户端，用户在浏览其他页面时，客户端验证登录状态，Nginx将请求转发至服务器B，由于B上并没有对应客户端发来sessionId的session，所以会重新创建一个新的session，并且再将这个新的sessionID返回给客户端，这样，我们可以想象一下，用户每一次操作都有1/2的概率进行再次的登录，这样不仅对用户体验特别差，还会让服务器上的session激增，加大服务器的运行压力。

为了解决集群环境下的seesion共享问题，共有4种解决方案：

1.粘性session
粘性session是指Ngnix每次都将同一用户的所有请求转发至同一台服务器上，即将用户与服务器绑定。
2.服务器session复制
即每次session发生变化时，创建或者修改，就广播给所有集群中的服务器，使所有的服务器上的session相同。
3.session共享
缓存session，使用redis， memcached。
4.session持久化

将session存储至数据库中，像操作数据一样才做session。

memcached与redis的区别？
1、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。而memcache只支持简单数据类型，需要客户端自己处理复杂对象

2、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用（PS：持久化在rdb、aof）。

3、由于Memcache没有持久化机制，因此宕机所有缓存数据失效。Redis配置为持久化，宕机重启后，将自动加载宕机时刻的数据到缓存系统中。具有更好的灾备机制。

4、Memcache可以使用Magent在客户端进行一致性hash做分布式。Redis支持在服务器端做分布式（PS:Twemproxy/Codis/Redis-cluster多种分布式实现方式）

5、Memcached的简单限制就是键（key）和Value的限制。最大键长为250个字符。可以接受的储存数据不能超过1MB（可修改配置文件变大），因为这是典型slab 的最大值，不适合虚拟机使用。而Redis的Key长度支持到512k。

6、Redis使用的是单线程模型，保证了数据按顺序提交。Memcache需要使用cas保证数据一致性。CAS（Check and Set）是一个确保并发一致性的机制，属于“乐观锁”范畴；原理很简单：拿版本号，操作，对比版本号，如果一致就操作，不一致就放弃任何操作

cpu利用。由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更 高。而在100k以上的数据中，Memcached性能要高于Redis 。

7、memcache内存管理：使用Slab Allocation。原理相当简单，预先分配一系列大小固定的组，然后根据数据大小选择最合适的块存储。避免了内存碎片。（缺点：不能变长，浪费了一定空间）memcached默认情况下下一个slab的最大值为前一个的1.25倍。

8、redis内存管理： Redis通过定义一个数组来记录所有的内存分配情况， Redis采用的是包装的malloc/free，相较于Memcached的内存 管理方法来说，要简单很多。由于malloc 首先以链表的方式搜索已管理的内存中可用的空间分配，导致内存碎片比较多

---

第十部分：

Java实现线程有哪几种方式？
1、继承Thread类实现多线程
2、实现Runnable接口方式实现多线程
3、使用ExecutorService、Callable、Future实现有返回结果的多线程

多线程同步有哪几种方法？

Synchronized关键字，Lock锁实现，分布式锁等。

Runnable和Thread用哪个好？
Java不支持类的多重继承，但允许你实现多个接口。所以如果你要继承其他类，也为了减少类之间的耦合性，Runnable会更好。

Java中notify和notifyAll有什么区别？
notify()方法不能唤醒某个具体的线程，所以只有一个线程在等待的时候它才有用武之地。而notifyAll()唤醒所有线程并允许他们争夺锁确保了至少有一个线程能继续运行。

为什么wait/notify/notifyAll这些方法不在thread类里面？
这是个设计相关的问题，它考察的是面试者对现有系统和一些普遍存在但看起来不合理的事物的看法。回答这些问题的时候，你要说明为什么把这些方法放在Object类里是有意义的，还有不把它放在Thread类里的原因。一个很明显的原因是JAVA提供的锁是对象级的而不是线程级的，每个对象都有锁，通过线程获得。如果线程需要等待某些锁那么调用对象中的wait()方法就有意义了。如果wait()方法定义在Thread类中，线程正在等待的是哪个锁就不明显了。简单的说，由于wait，notify和notifyAll都是锁级别的操作，所以把他们定义在Object类中因为锁属于对象。

为什么wait和notify方法要在同步块中调用？
主要是因为Java API强制要求这样做，如果你不这么做，你的代码会抛出IllegalMonitorStateException异常。还有一个原因是为了避免wait和notify之间产生竞态条件。

什么是死锁？如何避免死锁？
死锁就是两个线程相互等待对方释放对象锁。

启动线程方法start()和run()有什么区别？
只有调用了start()方法，才会表现出多线程的特性，不同线程的run()方法里面的代码交替执行。如果只是调用run()方法，那么代码还是同步执行的，必须等待一个线程的run()方法里面的代码全部执行完毕之后，另外一个线程才可以执行其run()方法里面的代码。

多线程之间如何进行通信？
wait/notify

什么是线程池？
很简单，简单看名字就知道是装有线程的池子，我们可以把要执行的多线程交给线程池来处理，和连接池的概念一样，通过维护一定数量的线程池来达到多个线程的复用。

线程池的好处
我们知道不用线程池的话，每个线程都要通过new Thread(xxRunnable).start()的方式来创建并运行一个线程，线程少的话这不会是问题，而真实环境可能会开启多个线程让系统和程序达到最佳效率，当线程数达到一定数量就会耗尽系统的CPU和内存资源，也会造成GC频繁收集和停顿，因为每次创建和销毁一个线程都是要消耗系统资源的，如果为每个任务都创建线程这无疑是一个很大的性能瓶颈。所以，线程池中的线程复用极大节省了系统资源，当线程一段时间不再有任务处理时它也会自动销毁，而不会长驻内存。

什么是活锁、饥饿、无锁、死锁？
死锁、活锁、饥饿是关于多线程是否活跃出现的运行阻塞障碍问题，如果线程出现了这三种情况，即线程不再活跃，不能再正常地执行下去了。

死锁

死锁是多线程中最差的一种情况，多个线程相互占用对方的资源的锁，而又相互等对方释放锁，此时若无外力干预，这些线程则一直处理阻塞的假死状态，形成死锁。

举个例子，A同学抢了B同学的钢笔，B同学抢了A同学的书，两个人都相互占用对方的东西，都在让对方先还给自己自己再还，这样一直争执下去等待对方还而又得不到解决，老师知道此事后就让他们相互还给对方，这样在外力的干预下他们才解决，当然这只是个例子没有老师他们也能很好解决，计算机不像人如果发现这种情况没有外力干预还是会一直阻塞下去的。

活锁

活锁这个概念大家应该很少有人听说或理解它的概念，而在多线程中这确实存在。活锁恰恰与死锁相反，死锁是大家都拿不到资源都占用着对方的资源，而活锁是拿到资源却又相互释放不执行。当多线程中出现了相互谦让，都主动将资源释放给别的线程使用，这样这个资源在多个线程之间跳动而又得不到执行，这就是活锁。

饥饿

我们知道多线程执行中有线程优先级这个东西，优先级高的线程能够插队并优先执行，这样如果优先级高的线程一直抢占优先级低线程的资源，导致低优先级线程无法得到执行，这就是饥饿。当然还有一种饥饿的情况，一个线程一直占着一个资源不放而导致其他线程得不到执行，与死锁不同的是饥饿在以后一段时间内还是能够得到执行的，如那个占用资源的线程结束了并释放了资源。

无锁

无锁，即没有对资源进行锁定，即所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。无锁典型的特点就是一个修改操作在一个循环内进行，线程会不断的尝试修改共享资源，如果没有冲突就修改成功并退出否则就会继续下一次循环尝试。所以，如果有多个线程修改同一个值必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。之前的文章我介绍过JDK的CAS原理及应用即是无锁的实现。

可以看出，无锁是一种非常良好的设计，它不会出现线程出现的跳跃性问题，锁使用不当肯定会出现系统性能问题，虽然无锁无法全面代替有锁，但无锁在某些场合下是非常高效的。

Synchronized有哪几种用法？
锁类、锁方法、锁代码块。

Fork/Join框架是干什么的？
大任务自动分散小任务，并发执行，合并小任务结果。

Java中用到了什么线程调度算法？
抢占式。一个线程用完CPU之后，操作系统会根据线程优先级、线程饥饿情况等数据算出一个总的优先级并分配下一个时间片给某个线程执行。