JAVA面试汇总

1. IOC控制反转的优点？
  将对象的创建权交付于IOC容器进行托管，使得具有如下优点
  - a. 统一管理；
  - b. 以工厂模式对用户提供对象，罗列对象组供用户进行挑选，使得逻辑更清晰；
  - c. 不需要用户直接new对象，可以在获取对象的时候做些额外的操作（getBean()方法进行）;
1. dubbo 提供者和dubbo的消费者是如何进行通信的，dubbo提供者数据变更，消费者如何感知？
  - a. Dubbo启动时，Consumer和Provider都会把自身的URL格式化为字符串，然后注册到zookeeper相应节点下，作为一个临时节点，当连断开时，节点被删除；
  - b. Consumer在启动时，不仅仅会注册自身到 …/consumers/目录下，同时还会订阅…/providers目录，实时获取其上Provider的URL字符串信息。
  - c. Provider和Consumer向Zookeeper注册临时节点，当连接断开时删除相应的注册节点。
  - d. Consumer订阅Providers节点的子节点，实时感知Provider的变化情况，实时同步自身的Invoker对象，保证RPC的可用性。
    
    image.png
1. CGLIB和JDK提供的InvocationHandler代理对象生成对应代理情况是在哪个步骤中完成的？
  CGLIB是在代码运行时对字节码进行修改和动态生成，继承子类覆写目标类方法，JDK提供的则需要有接口类作为前提，在运行时动态生成。
4.JWT如何在token上做对WEB服务器无状态处理？
JWT的token分为三部分：header、payload、signature，signature对header和payload数据进行签名。
5.1 MYSQL的协议格式？

总体流程

===========传输层协议================
1. 三次握手建立 TCP 连接。
===========应用层协议================
2. 建立 MySQL 连接，也就是认证阶段。
    服务端 -> 客户端：发送握手初始化包 (Handshake Initialization Packet)。
    客户端 -> 服务端：发送验证包 (Client Authentication Packet)。
    服务端 -> 客户端：认证结果消息。
 
3. 认证通过之后，客户端开始与服务端之间交互，也就是命令执行阶段。
    客户端 -> 服务端：发送命令包 (Command Packet)。
    服务端 -> 客户端：发送回应包 (OK Packet, or Error Packet, or Result Set Packet)。
 
4. 断开 MySQL 连接。
    客户端 -> 服务器：发送退出命令包。
 ==========传输层协议==================
5. 四次握手断开 TCP 连接

服务端发送至客户端的协议格式：

image.png

协议版本号：服务端所使用的mysql协议的版本号
服务器线程ID：服务端为此客户端所创建的线程的ID
挑战随机数：MySQL数据库用户认证采用的是挑战/应答的方式，服务器生成该挑战数并发送给客户端，由客户端进行处理并返回相应结果，然后服务器检查是否与预期的结果相同，从而完成用户认证的过程。
服务器权能标志：用于与客户端协商通讯方式

客户端发送至服务器端：

image.png

客户端权能标志：客户端收到服务器发来的初始化报文后，会对服务器发送的权能标志进行修改，保留自身所支持的功能，然后将权能标返回给服务器，从而保证服务器与客户端通讯的兼容性。
消息长度：客户端发送请求时所支持的最大消息长度值
字符编码表示通讯过程中使用的字符编码，与服务器在认证报文中发送的相同
用户名：客户端登陆的用户名
挑战认证数据：客户端用户密码使用服务器发送的挑战随机数进行加密后，生成挑战认证数据，返回给服务器用于服务端的认证

认证流程：

服务器发送随机字符串 (scramble) 给客户端。
客户端作如下计算，然后客户端将 token 发送给服务端。

stage1_hash = SHA1(明文密码)

token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash

服务端作如下计算，比对 SHA1(stage1_hash) 和 mysql.user.password 是否相同。

stage1_hash = token XOR SHA1(scramble + mysql.user.password)

5.2 MYSQL的innodb引擎重要的几个参数优化？
内存优化参数：
- innodb_buffer_pool_size：主要缓存innodb表的索引，数据，插入数据时的缓冲，建议设置成内存的60%~70%。
- innodb_additional_mem_pool_size：存放Innodb的内部目录，这个值不用分配太大，系统可以自动调。通常设置16Ｍ够用了，如果表比较多，可以适当的增大。
  日志优化参数
- innodb_log_file_size：这个值分配的大小和数据库的写入速度，事务大小，异常重启后的恢复有很大的关系。一般取256M可以兼顾性能和recovery的速度。
- innodb_log_buffer_size：事务在内存中的缓冲，也就是日志缓冲区的大小，默认设置即可，具有大量事务的可以考虑设置为16M
- innodb_flush_logs_at_trx_commit：这个参数只有3个值（0：每秒写入，1每次提交写入，2事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作）.默认为1，性能更高的可以设置为0或是2，这样可以适当的减少磁盘IO（但会丢失一秒钟的事务。），游戏库的MySQL建议设置为0。主库请不要更改了。
  IO分配
- innodb_file_per_table：使每个Innodb的表，有自已独立的表空间。如删除文件后可以回收那部分空间。默认是关闭的，建议打开（innodb_file_per_table=1）
- innodb_open_files：限制Innodb能打开的表的数据。
- innodb_data_home_dir：放置表空间数据的目录，默认在mysql的数据目录，设置到和MySQL安装文件不同的分区可以提高性能。
6.zookeeper如何保证数据一致性？
Paxos算法（参考后续文章《Paxos算法》）比较复杂，为了简化实现，Zookeeper使用了一种叫ZAB（ZooKeeper Atomic
Broadcast，ZooKeeper原子消息广播协议）的算法协议。基于ZAB算法，Zookeeper集群保证数据更新的一致性，并且通过集群方式保证了Zookeeper系统高可用。但是Zookeeper系统中所有服务器都存储相同的数据，也就是数据没有分片存储，因此不满足分区耐受性。
因为Zookeeper系统的多台服务器存储相同的数据并且每次数据更新都要所有服务器投票表决，所以和一般的分布式系统相反，Zookeeper集群的性能会随着服务器数量的增加而下降。
7.kafka如何保证数据一致性及重试不出现数据重复机制、kafka的partition的几种优点？
参考后续文章《kafka基础原理》