【面试】JAVA三年经验面试题（二）

1.volitile

    volatile保证可见性之前，先来说说什么叫可见性。谈到可见性，又不得不说JMM(java memory model)内存模型。JMM内存模型是逻辑上的划分，及并不是真实存在。Java线程之间的通信就由JMM控制。JMM的抽象示意图如下：

如上图所示，我们定义的共享变量，是存储在主内存中的，也就是计算机的内存条中。线程A去操作共享变量的时候，并不能直接操作主内存中的值，而是将主内存中的值拷贝回自己的工作内存中，在工作内存中做修改。修改好后，在将值刷回到主内存中。

     volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。
     所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了。当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

2.synchronized

     用来保证原子性、可见性、有序性
     会在编译后的字节码中在使用synchronized关键字的前后加入monitorenter,monitorexcit指令。

     Java中的每一个对象都可以作为锁。具体表现为以下3种形式。
❑ 对于普通同步方法，锁是当前实例对象。
❑ 对于静态同步方法，锁是当前类的Class对象。
❑ 对于同步方法块，锁是Synchonized括号里配置的对象。

synchronized关键字底层优化，存在锁升级，不存在锁降级

偏向锁->轻量级锁->重量级锁

偏向锁：
大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，
会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。
如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：

轻量级锁：
如果MarkWord不是自己的ThreadId,锁升级，这时候，用CAS来执行切换，新的线程根据MarkWord里面现有的ThreadId，通知之前线程暂停，之前线程将Markword的内容置为空。
两个线程都把对象的Mark Word复制到自己新建的用于存储锁的记录空间（在当前线程的栈帧中建立一个名为Lock Record的空间，官方把这份拷贝称为Displaced Mark Word），
接着开始通过CAS操作，把共享对象的MarKword更新为指向Lock Record的指针。

重量级锁：
自旋的线程在自旋过程中，成功获得资源(即之前获的资源的线程执行完成并释放了共享资源)，则整个状态依然处于轻量级锁的状态，如果自旋失败则进入重量级锁的状态，
这个时候，自旋的线程进行阻塞，等待之前线程执行完成并唤醒自己，需要从用户态切换到内核态实现。

简而言之，只有一个线程在访问就是偏向锁，除了持有锁的线程外，还有另外一个线程在竞争就是轻量级锁。除了持有锁的线程外有多个线程在竞争锁，重量级锁。

3.MySQL两种索引区别

MyISAM 索引实现
     MyISAM 引擎使用 B+Tree 作为索引结构,叶节点的 data 域存放的是数据记录的地址。MyISAM 中索引检索的算法为首先按照 B+Tree 搜索算法搜索索引,如果指定的 Key 存在,
则取出其data 域的值,然后以 data 域的值为地址,读取相应数据记录。MyISAM 的索引方式也叫做“非聚集索引

InnoDB 索引实现

     虽然 InnoDB 也使用 B+Tree 作为索引结构,但具体实现方式却与 MyISAM 截然不同。

1.第一个重大区别是 InnoDB 的数据文件本身就是索引文件。从上文知道,MyISAM 索引文件和数据文件是分离的,索引文件仅保存数据记录的地址。
而在InnoDB 中,表数据文件本身就是按 B+Tree 组织的一个索引结构,这棵树的叶点data 域保存了完整的数据记录。这个索引的 key 是数据表的主键,因此 InnoDB 表数据文件本身就是主索引

2 .InnoDB 要求表必须有主键(MyISAM 可以没有),如果没有显式指定,则 MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL自动为 InnoDB 表生成一个隐含字段作为主键,类型为长整形。 同时,请尽量在 InnoDB 上采用自增字段做表的主键。因为 InnoDB 数据文件本身是一棵B+Tree,非单调的主键会造成在插入新记录时数据文件为了维持 B+Tree 的特性而频繁的分裂调整,十分低效,而使用自增字段作为主键则是一个很好的选择。如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟一个新的页

3.与 MyISAM 索引的不同是 InnoDB 的辅助索引 data 域存储相应记录主键的值而不是地址。换句话说,InnoDB 的所有辅助索引都引用主键作为 data 域。

4.B树和B+树的区别

都是多叉平衡查找树
(1)B+树查询时间复杂度固定是O(logN)，B树查询复杂度最好是 O(1)。
(2)B+树相邻接点的指针可以大大增加区间访问性，可使用在范围查询等，而B树每个节点 key 和 data 在一起，则无法区间查找。
(3)B+树更适合外部存储，也就是磁盘存储。由于内节点无 data 域，每个节点能索引的范围更大更精确。
(4)注意这个区别相当重要，是基于(1)(2)(3)的，B树每个节点即保存数据又保存索引，所以访问磁盘IO的次数多，B+树只有叶子节点保存，访问磁盘IO数量少，并且区间访问比较好。

5.分布式锁原理

1.通过lua脚本让加锁操作和设置过期时间操作成为原子操作
2.互斥锁，线程1加锁，线程2加锁请求返回锁的剩余时间，线程2自旋
3.watchDog 后台线程，每隔10S检查一下，如果线程1依然持有锁，进行锁续命
4.可重入锁，线程1进行多次LOCK，第一个if判断肯定不成立，“exists myLock”会显示锁key已经存在了。第二个if判断会成立，因为myLock的hash数据结构中包含的那个ID
incrby myLock 通过这个命令，对客户端1的加锁次数，累加1。
5.释放锁机制。如果执行lock.unlock()，就可以释放分布式锁，就是每次都对myLock数据结构中的那个加锁次数减1。如果发现加锁次数是0了，说明这个客户端已经不再持有锁了，此时就会用：“del myLock”命令，从redis里删除这个key。

6.RabbitMQ工作模式

简单模式：一个生产者，一个消费者
work模式：一个生产者，多个消费者，每个消费者获取到的消息唯一。
订阅模式：一个生产者发送的消息会被多个消费者获取。
路由模式：发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key
topic模式：将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“*”只匹配一个词。

高可用：单机、普通集群模式（无高可用性）、镜像集群模式（高可用性）
这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，
就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。

7.Eurka 工作流程

了解完 Eureka 核心概念，自我保护机制，以及集群内的工作原理后，我们来整体梳理一下 Eureka 的工作流程：

1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息
2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务
3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常
4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例
5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端
6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式
7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地
8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存
9、Eureka Client 获取到目标服务器信息，发起服务调用
10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除

8.Dubbo原理

第一层：service 层，接口层，给服务提供者和消费者来实现的
第二层：config 层，配置层，主要是对 dubbo 进行各种配置的
第三层：proxy 层，服务代理层，无论是 consumer 还是 provider，dubbo 都会给你生成代理，代理之间进行网络通信
第四层：registry 层，服务注册层，负责服务的注册与发现
第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合     成一个服务
第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控
第七层：protocal 层，远程调用层，封装 rpc 调用
第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步
第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口
第十层：serialize 层，数据序列化层

工作流程
第一步：provider 向注册中心去注册
第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务
第三步：consumer 调用 provider
第四步：consumer 和 provider 都异步通知监控中心

9.ZooKeeper

Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题。ZooKeeper 提供的服务包括：
分布式消息同步和协调机制、服务器节点动态上下线统一配置管理、负载均衡、集群管理等。
ZooKeeper 提供基于类似于 Linux 文件系统的目录节点树方式的数据存储，空间。Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化，通过监控这些数据状态的变化，从而可以达到基于数据的集群管理
ZooKeeper 节点的数据上限是 1MB。