记一次电话面试，谈谈面试中的那些奇葩问题！

HS公司，202009121700~202009121750

老生常谈的问题，首先是自我介绍

主要说了下再当前公司用什么语言什么框架做了什么！

1、你们公司用的是微服务架构，你能说说微服务架构与SOA架构相比，有什么优缺点？

SOA（面向服务的架构）：是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务架构：是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

SOA：

•  微服务剔除SOA中复杂的ESB企业服务总线，所有的业务智能逻辑在服务内部处理，使用Http（Rest API）进行轻量化通讯
• 强调按水平架构划分为：前、后端、数据库、测试等，微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品
• SOA将组件以library的方式和应用部署在同一个进程中运行，微服务则是各个服务独立运行。
• SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构）
• 微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
• 传统应用倾向于使用统一的技术平台来解决所有问题，微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。

 

微服务架构：

• 独立部署，灵活扩展 (传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（如用户服务、商品服务等）为单位进行部署。)

•  资源的有效隔离  微服务设计原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效的避免了服务之间争用数据库和缓存资源所带来的问题。同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。

• 团队组织架构的调整  微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构。

• 微服务架构的不足之处：

  （1）      微服务把原有的项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度。

  （2）      微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战。

2、微服务架构你们都用了哪些组件？

　　2.1、分布式：不同的功能模块部署在不同的服务器上，减轻网站高并发带来的压力。

　　2.2、集群：多台服务器上部署相同应用构成一个集群，通过负载均衡共同向外提供服务。

　　2.3、微服务：微服务架构模式就是将web应用拆分为一系列小的服务模块，这些模块可以独立地编译、部署，并通过各自暴露的API接口通讯，共同组成一个web应用。

　　2.4、SpringCloud是基于SpringBoot的一整套微服务框架，提供了一系列可配置的组件，如配置管理、服务发现、负载均衡、熔断器、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。

微服务架构特点

• 单一职责
• 面向服务
• 服务自治(数据库分离、前后端分离、部署独立、服务间http调用、团队独立)

• 1：约定优于配置

  2：开箱即用、快速启动

  3：适用于各种环境

  4：轻量级的组件

  5：组件支持丰富，功能齐全

组件

• Eureka（Zookeeper），服务注册中心
• Zuul，API服务网关
• Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式
• Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合
• Sleuth-链路跟踪
• Ribbon，客户端负载均衡 
• Feign，声明式服务调用 动态代理
• Bus，消息总线

MySQL有几种存储引擎，使用场景？

5.6 的有九种，MyISAM、InnoDB，主要说说这两种的区别

InnoDB 行级锁、支持事务、聚簇索引、支持外键、更消耗存储空间、行级锁

MyISAM 表级锁、不支持事务、非聚簇索引、表级锁

exist 和 in有什么区别？

数据量较少

 

 

exist：适合子查询中表数据大于外查询表中数据

in：适合外部表数据大于子查询的表数

区别：如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。其实我们区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键)，如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询，所以我们会以驱动表的快速返回为目标，那么就会考虑到索引及结果集的关系了 ，另外IN时不对NULL进行处理。

in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询。

一直以来认为exists比in效率高的说法是不准确的

 

exist： 先执行外部查询语句，然后在执行子查询，子查询中它每次都会去执行数据库的查询，执行次数等于外查询的数据数量。查询数据库比较频繁(记住这点),如果b表再id上加了索引也会走索引

 select * from a where exist(select 1  from b.a_id=a.id);

       //外部查询

       Object[] out={select *  from a};

        List<Object> result=new ArrayList();

       for（int i=0;i<out.size();i++）{

              //子查询(内查询)

               //1 去查询数据库

               // 2 判断外部数据的值执行第一步是是否能查到数据，返回 ture或者false 

              // 3 如果第二部为true

              if（exiset(out[i].id)）{//执行  select * fron b where b.a_id=a.id;  会执行 out.size();次

                   result.add(out[i]));

               } 

       }

如果a表中的数据越大那么 子查询查询的次数就会越多，这样对效率就很慢

例如:

1. 表a中100000条数据,表b中100条数据，查询数据库次数=1(表a查一次)+100000(子查询：查询表b的次数)  ，一共          100001次
2. 表a中 100条数据，表b100000条，查询数据库次数=1(表a查一次)+100(子查询次数)，一共 101次，可见只有当子查询的表数量远远大于外部表数据的是否用exist查询效率好

in:  先查询 in()子查询的数据(1次)，并且将数据放进内存里(不需要多次查询),然后外部查询的表再根据查询的结果进行查询过

滤

EXISTS与IN的使用效率：通常情况下采用exists要比in效率高，因为IN不走索引，但要看实际情况具体使用：
IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。

 

分布式事务如何保证？如下订单后通知扣款、减库存，前面事务提交了，扣库存回滚了怎么处理？

微服务架构必然会有子事务的情况，保证分布式事务成功，必须每个子事务都成功。如果不能原子，则全部回滚。

1、扣库存失败，则可以自己监听自己，利用MQ，再次消费！

2、消息落库，再次消费

3、重试次数到，依然不成功，子事务回滚

联合查询时是大表在前还是小表在前？

一般而言，应小表在前，但也不是绝对的！

case 1: 两张表都没有索引
nature join会对两个表做全表扫描。

大致过程是从前表中load 一个输入缓冲区大小的数据块进内存，然后从后表中load 一个输入缓冲区大小的数据进内存，然后两个输入缓冲区中的数据做nature join，join结果写进输出缓冲区。然后后表的输入缓冲区清空，再从后表中load 第二块输入缓冲区大小的数据，继续和前表输入缓冲区中的数据做nature join，将结果写进输出缓冲区。以此类推，当后表遍历完一遍之后，前表load第二块输入缓冲区大小的数据，后表再依次load 第一块，第二块，到第n块。
那cost 是多少呢？比如前表有a块缓冲区大小的数据，后表有b块缓冲区大小的数据，那cost 就是 a*b*（transfer time）+ 2a * （seek time）+ a*（transfer time），其中 transfer time 表示一块缓冲区大小的数据从硬盘load 到内存的时间，seek time表示磁盘块的寻址时间
所以，前表较小的时候（即a较小的时候），总体时间会小。
结论：小表在前好

case 2: 小表无索引，大表有索引，且基于索引列做nature join
这种情况，必须小表在前，但小表在前，有多大的性能提升，要看大表的索引类型。
大表聚集索引，性能提升较大
大表非聚集索引，性能有可能同全表扫描差不多。
结论：小表在前好

case 3: 小表有索引，大表无索引，而且是基于索引列做nature join
这种情况需要关注大表在前，使用小表索引，会带来性能提升。
小表非聚集索引，性能有可能同全表扫描差不多，那性能就赶不上小表在前了
小表聚集索引，性能可能提升较大
结论：大小表谁在前不一定，需要看小表的索引情况和大小表的相对数据量大小

微服务的链路追踪原理有了解么？

链路追踪的出现正是为了解决这种问题，它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。

如果想知道一个接口在哪个环节出现了问题，就必须清楚该接口调用了哪些服务，以及调用的顺序，如果把这些服务串起来，看起来就像链条一样，我们称其为调用链。

想要实现调用链，就要为每次调用做个标识，然后将服务按标识大小排列，可以更清晰地看出调用顺序，我们暂且将该标识命名为spanid。实际场景中，我们需要知道某次请求调用的情况，所以只有spanid还不够，得为每次请求做个唯一标识，这样才能根据标识查出本次请求调用的所有服务，而这个标识我们命名为traceid。现在根据spanid可以轻易地知道被调用服务的先后顺序，但无法体现调用的层级关系，正如下图所示，多个服务可能是逐级调用的链条，也可能是同时被同一个服务调用。所以应该每次都记录下是谁调用的，我们用parentid作为这个标识的名字。到现在，已经知道调用顺序和层级关系了，但是接口出现问题后，还是不能找到出问题的环节，如果某个服务有问题，那个被调用执行的服务一定耗时很长，要想计算出耗时，上述的三个标识还不够，还需要加上时间戳，时间戳可以更精细一点，精确到微秒级。只记录发起调用时的时间戳还算不出耗时，要记录下服务返回时的时间戳，有始有终才能算出时间差，既然返回的也记了，就把上述的三个标识都记一下吧，不然区分不出是谁的时间戳。

Sleuth是Spring Cloud的组件之一，它为Spring Cloud实现了一种分布式追踪解决方案，兼容Zipkin，HTrace和其他基于日志的追踪系统，例如 ELK（Elasticsearch 、Logstash、 Kibana）。

cs （Client Sent） - 客户端发起一个请求，这个注释指示了一个Span的开始。

sr （Server Received） - 服务端接收请求并开始处理它，如果用 sr 时间戳减去 cs 时间戳便能看出有多少网络延迟。

ss（Server Sent）- 注释请求处理完成(响应已发送给客户端)，如果用 ss 时间戳减去sr 时间戳便可得出服务端处理请求耗费的时间。

cr（Client Received）- 预示了一个 Span的结束，客户端成功地接收到了服务端的响应，如果用 cr 时间戳减去 cs 时间戳便可得出客户端从服务端获得响应所需耗费的整个时间。

（注册中心）微服务的健康检测知道原理吗？

心跳，连续多次未收到客户端的心跳应答，自我保护。Eureca

客户端与zookeeper服务端断开连接后，该节点被删除。临时节点下，不存在子节点。监听+事件机制 keep alive

Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

反射了解么？有在项目中使用过反射么？

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

   获取类的作用域、方法、注解、获取对象的类等

多线程，JDK和Spring的你了解么？

1、jdk有自带的线程池、spirng也有，都是对一个接口扩展。

异步调用是相对于同步调用而言的，同步调用是指调用方同步等待被调用执行完毕后才进行下一步操作

异步调用则无需等待上一步程序执行完即可继续执行。

2、如何实现异步调用？

使用多线程，这是很多人第一眼想到的关键词，没错，多线程就是一种实现异步调用的方式。

在非spring目项目中我们要实现异步调用的就是使用多线程方式，可以自己实现Runable接口或者集成Thread类，或者使用jdk1.5以上提供了的Executors线程池。

StrngBoot中则提供了很方便的方式执行异步调用。

TaskExecutor：Spring异步线程池的接口类，其实质是java.util.concurrent.Executor
同时使用多线程为了减少开销可以用线程池。

Java通过Executors类可以创建四种线程池，他们分别是newCachedThreadPool，newFixedThreadPool，newScheduledThreadPool，newSingleThreadExecutor

Spring Bean 生命周期？

Spring Bean 生命周期

你遇到的最难解决的问题？

记一次数据库数据数据记录异常问题

Redis 单机模式、主从架构 与 哨兵模式、集群模式 的区别？

单机模式

Redis 单副本，采用单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

1. 架构简单，部署方便。
2. 高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务。
3. 高性能。

缺点：

1. 不保证数据的可靠性。
2. 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。
3. 高性能受限于单核 CPU 的处理能力(Redis 是单线程机制)，CPU 为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用 Memcached 替代。

 

主从模式

Redis 采用主从(可以多从)部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

优点：

1. 高可靠性：一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行;另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。
2. 读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。

缺点：

1. 故障恢复复杂，如果没有 RedisHA 系统(需要开发)，当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其它从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。
2. 主库的写能力受到单机的限制，可以考虑分片。
3. 主库的存储能力受到单机的限制，可以考虑 Pika。
4. 原生复制的弊端在早期的版本中也会比较突出，如：Redis 复制中断后，Slave 会发起 psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于 COW 机制，导致极端情况下的主库内存溢出，程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘 IO 和 CPU(压缩)资源消耗;发送数 GB 大小的备份文件导致服务器出口带宽暴增，阻塞请求，建议升级到最新版本。

哨兵模式

Redis Sentinel 是 2.8 版本后推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel 集群和 Redis 数据集群。其中 Redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel 的节点数量要满足 2n+1(n>=1)的奇数个。

优点：

1. Redis Sentinel 集群部署简单。
2. 能够解决 Redis 主从模式下的高可用切换问题。
3. 很方便实现 Redis 数据节点的线形扩展，轻松突破 Redis 自身单线程瓶颈，可极大满足 Redis 大容量或高性能的业务需求。
4. 可以实现一套 Sentinel 监控一组 Redis 数据节点或多组数据节点。

缺点：

1. 部署相对 Redis 主从模式要复杂一些，原理理解更繁琐。
2. 资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务。
3. Redis Sentinel 主要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点做失败判定分为主观下线和客观下线两种，对于 Redis 的从节点有对节点做主观下线操作，并不执行故障转移。
4. 不能解决读写分离问题，实现起来相对复杂。

集群模式

Redis Cluster 是 3.0 版后推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。Redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。

优点：

1. 无中心架构。
2. 数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
3. 可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除。
4. 高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升。
5. 降低运维成本，提高系统的扩展性和可用性。

缺点：

1. Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
2. 节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout)，被判断下线，这种 failover 是没有必要的。
3. 数据通过异步复制，不保证数据的强一致性。
4. 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
5. Slave 在集群中充当“冷备”，不能缓解读压力，当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率。
6. Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 由于 Keys 不支持跨 slot 查询，所以执行 mset、mget、sunion 等操作支持不友好。
7. Key 事务操作支持有限，只支持多 key 在同一节点上的事务操作，当多个 Key 分布于不同的节点上时无法使用事务功能。
8. Key 作为数据分区的最小粒度，不能将一个很大的键值对象如 hash、list 等映射到不同的节点。
9. 不支持多数据库空间，单机下的 redis 可以支持到 16 个数据库，集群模式下只能使用 1 个数据库空间，即 db 0。
10. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
11. 避免产生 hot-key，导致主库节点成为系统的短板。
12. 避免产生 big-key，导致网卡撑爆、慢查询等。
13. 重试时间应该大于 cluster-node-time 时间。
14. Redis Cluster 不建议使用 pipeline 和 multi-keys 操作，减少 max redirect 产生的场景。

Java中的锁有哪些？

序号	锁名称	应用
1	乐观锁	CAS
2	悲观锁	synchronized、vector、hashtable
3	自旋锁	CAS
4	可重入锁	synchronized、Reentrantlock、Lock
5	读写锁	ReentrantReadWriteLock，CopyOnWriteArrayList、CopyOnWriteArraySet
6	公平锁	Reentrantlock(true)
7	非公平锁	synchronized、reentrantlock(false)
8	共享锁	ReentrantReadWriteLock中读锁
9	独占锁	synchronized、vector、hashtable、ReentrantReadWriteLock中写锁
10	重量级锁	synchronized
11	轻量级锁	锁优化技术
12	偏向锁	锁优化技术
13	分段锁	concurrentHashMap
14	互斥锁	synchronized
15	同步锁	synchronized
16	死锁	相互请求对方的资源
17	锁粗化	锁优化技术
18	锁消除	锁优化技术

乐观锁是一种乐观思想，假定当前环境是读多写少，遇到并发写的概率比较低，读数据时认为别的线程不会正在进行修改（所以没有上锁）。写数据时，判断当前 与期望值是否相同或者版本号是否相同，如果相同则进行更新（更新期间加锁，保证是原子性的）。

Java中的乐观锁： CAS，比较并替换，比较当前值（主内存中的值），与预期值（当前线程中的值，主内存中值的一份拷贝）是否一样，一样则更新，否则继续进行CAS操作。

如上图所示，可以同时进行读操作，读的时候其他线程不能进行写操作。

悲观锁是一种悲观思想，即认为写多读少，遇到并发写的可能性高，每次去拿数据的时候都认为其他线程会修改，所以每次读写数据都会认为其他线程会修改，所以每次读写数据时都会上锁。其他线程想要读写这个数据时，会被这个线程block，直到这个线程释放锁然后其他线程获取到锁。

Java中的悲观锁： synchronized修饰的方法和方法块、ReentrantLock。

如上图所示，只能有一个线程进行读操作或者写操作，其他线程的读写操作均不能进行。

自旋锁是一种技术： 为了让线程等待，我们只须让线程执行一个忙循环（自旋）。

现在绝大多数的个人电脑和服务器都是多路（核）处理器系统，如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。

自旋锁的优点： 避免了线程切换的开销。挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性能带来了很大的压力。

自旋锁的缺点： 占用处理器的时间，如果占用的时间很长，会白白消耗处理器资源，而不会做任何有价值的工作，带来性能的浪费。因此自旋等待的时间必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。

自旋次数默认值：10次，可以使用参数-XX:PreBlockSpin来自行更改。

自适应自旋： 自适应意味着自旋的时间不再是固定的，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。有了自适应自旋，随着程序运行时间的增长及性能监控信息的不断完善，虚拟机对程序锁的状态预测就会越来越精准。

Java中的自旋锁： CAS操作中的比较操作失败后的自旋等待。

可重入锁是一种技术： 任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞。

可重入锁的原理： 通过组合自定义同步器来实现锁的获取与释放。

• 再次获取锁：识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。获取锁后，进行计数自增，

• 释放锁：释放锁时，进行计数自减。

Java中的可重入锁： ReentrantLock、synchronized修饰的方法或代码段。

可重入锁的作用： 避免死锁。

可重入锁如果加了两把，但是只释放了一把会出现什么问题？

答：程序卡死，线程不能出来，也就是说我们申请了几把锁，就需要释放几把锁。

如果只加了一把锁，释放两次会出现什么问题？

答：会报错，java.lang.IllegalMonitorStateException。

 

synchronized是Java中的关键字：用来修饰方法、对象实例。属于独占锁、悲观锁、可重入锁、非公平锁。

• 1.作用于实例方法时，锁住的是对象的实例(this)；

• 2.当作用于静态方法时，锁住的是 Class类，相当于类的一个全局锁， 会锁所有调用该方法的线程；

• 3.synchronized 作用于一个非 NULL的对象实例时，锁住的是所有以该对象为锁的代码块。它有多个队列，当多个线程一起访问某个对象监视器的时候，对象监视器会将这些线程存储在不同的容器中。

每个对象都有个 monitor 对象， 加锁就是在竞争 monitor 对象，代码块加锁是在代码块前后分别加上 monitorenter 和 monitorexit 指令来实现的，方法加锁是通过一个标记位来判断的

Lock： 是Java中的接口，可重入锁、悲观锁、独占锁、互斥锁、同步锁。

• 1.Lock需要手动获取锁和释放锁。就好比自动挡和手动挡的区别

• 2.Lock 是一个接口，而 synchronized 是 Java 中的关键字， synchronized 是内置的语言实现。

• 3.synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而 Lock 在发生异常时，如果没有主动通过 unLock()去释放锁，则很可能造成死锁现象，因此使用 Lock 时需要在 finally 块中释放锁。

• 4.Lock 可以让等待锁的线程响应中断，而 synchronized 却不行，使用 synchronized 时，等待的线程会一直等待下去，不能够响应中断。

• 5.通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。

• 6.Lock 可以通过实现读写锁提高多个线程进行读操作的效率。

synchronized的优势：

• 足够清晰简单，只需要基础的同步功能时，用synchronized。

• Lock应该确保在finally块中释放锁。如果使用synchronized，JVM确保即使出现异常，锁也能被自动释放。

• 使用Lock时，Java虚拟机很难得知哪些锁对象是由特定线程锁持有的。

ReentrantLock是Java中的类 ： 继承了Lock类，可重入锁、悲观锁、独占锁、互斥锁、同步锁。

划重点

相同点：

• 1.主要解决共享变量如何安全访问的问题

• 2.都是可重入锁，也叫做递归锁，同一线程可以多次获得同一个锁，

• 3.保证了线程安全的两大特性：可见性、原子性。

不同点：

• 1.ReentrantLock 就像手动汽车，需要显示的调用lock和unlock方法， synchronized 隐式获得释放锁。

• 2.ReentrantLock 可响应中断， synchronized 是不可以响应中断的，ReentrantLock 为处理锁的不可用性提供了更高的灵活性

• 3.ReentrantLock 是 API 级别的， synchronized 是 JVM 级别的

• 4.ReentrantLock 可以实现公平锁、非公平锁，默认非公平锁，synchronized 是非公平锁，且不可更改。

• 5.ReentrantLock 通过 Condition 可以绑定多个条件

锁粗化是一种优化技术： 如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作都是出现在循环体体之中，就算真的没有线程竞争，频繁地进行互斥同步操作将会导致不必要的性能损耗，所以就采取了一种方案：把加锁的范围扩展（粗化）到整个操作序列的外部，这样加锁解锁的频率就会大大降低，从而减少了性能损耗。JDK实现！

锁消除是一种优化技术： 就是把锁干掉。当Java虚拟机运行时发现有些共享数据不会被线程竞争时就可以进行锁消除。

那如何判断共享数据不会被线程竞争？

利用逃逸分析技术：分析对象的作用域，如果对象在A方法中定义后，被作为参数传递到B方法中，则称为方法逃逸；如果被其他线程访问，则称为线程逃逸。

在堆上的某个数据不会逃逸出去被其他线程访问到，就可以把它当作栈上数据对待，认为它是线程私有的，同步加锁就不需要了。

轻量级锁是JDK6时加入的一种锁优化机制： 轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量。轻量级是相对于使用操作系统互斥量来实现的重量级锁而言的。轻量级锁在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁将不会有效，必须膨胀为重量级锁。

优点： 如果没有竞争，通过CAS操作成功避免了使用互斥量的开销。

缺点： 如果存在竞争，除了互斥量本身的开销外，还额外产生了CAS操作的开销，因此在有竞争的情况下，轻量级锁比传统的重量级锁更慢。

zookeeper 选举过程？

节点（serviceId，zxid）

选举过程大致如下，假设有5台服务器均没有数据，编号分别是1,2,3,4,5,按编号依次启动

• 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
• 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
• 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
• 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
• 服务器5启动，后面的逻辑同服务器4成为小弟。