java 面试题

1.mybatis使用@param("xxx")注解传参和不使用的区别

区别是：使用注解可以不用加parameterType

2.mybatis二级缓存

配置二级缓存后，程序首先会从二级缓存中取数据，如果没有命中数据则会去查询一级缓存，如果再未命中则会去本地库查询数据。二级缓存查询地址和存储地址是不一致的，其原因是提交事务的必要。sqlSession.commit()这个方法了就是把之前存放在TransactionCache中的数据提交到二级缓存中，然后清空该数据。当第一次从数据库中查出数据后，会放到TransactionCache类中；当调用sqlSession.commit()方法，进行事务提交后，TransactionCache中的数据会提交到PerpetualCache中，查询二级缓存的数据就是在这个类中，同时，TransactionCache中的数据会清空。在事务提交之后，数据结果集对象就存放在了二级缓存中，所以第二次查询时，就可以从二级缓存中查询到数据了。进入TransactionalCache的getObject方法：

在更新操作，并提交事务后，清除了二级缓存，所以第二次查询时，是从数据库中查询的数据。

3.详解Spring依赖注入：@Autowired，@Resource和@Inject区别与实现原理

一、spring依赖注入使用方式

• @Autowired是spring框架提供的实现依赖注入的注解，主要支持在set方法，field，构造函数中完成bean注入，注入方式为通过类型查找bean，即byType的，如果存在多个同一类型的bean，则使用@Qualifier来指定注入哪个beanName的bean。
• 与JDK的@Resource的区别：@Resource是基于bean的名字，即beanName，来从spring的IOC容器查找bean注入的，而@Autowried是基于类型byType来查找bean注入的。
• 与JDK的@Inject的区别：@Inject也是基于类型来查找bean注入的，如果需要指定名称beanName，则可以结合使用@Named注解，而@Autowired是结合@Qualifier注解来指定名称beanName。

二、spring依赖注入注解的实现原理

注解处理器

• 在spring框架内部实现当中，注解实现注入主要是通过bean后置处理器BeanPostProcessor接口的实现类来生效的。BeanPostProcessor后置处理器是在spring容器启动时，创建bean对象实例后，马上执行的，对bean对象实例进行加工处理。
• @Autowired是通过BeanPostProcessor接口的实现类AutowiredAnnotationBeanPostProcessor来实现对bean对象对其他bean对象的依赖注入的；
• @Resource和@Inject是通过BeanPostProcessor接口的实现类CommonAnnotationBeanPostProcessor来实现的，其中如名字所述，即公共注解CommonAnotation，CommonAnnotationBeanPostProcessor是spring中统一处理JDK中定义的注解的一个BeanPostProcessor。该类会处理的注解还包括@PostConstruct，@PreDestroy等。

注解处理器的激活条件

• AutowiredAnnotationBeanPostProcessor和CommonAnnotationBeanPostProcessor添加到spring容器的BeanPostProcessor的条件，即激活这些处理器的条件如下：

1.基于xml的spring配置

 

• 在对应的spring容器的配置xml文件中，如applicationContext.xml，添加<context:annotation-config />和<context:component-scan />，或者只使用<context:component-scan />。
• 两者的区别是<context:annotation-config />只查找并激活已经存在的bean，如通过xml文件的bean标签生成加载到spring容器的，而不会去扫描如@Controller等注解的bean，查找到之后进行注入；而<context:component-scan />除了具有<context:annotation-config />的功能之外，还会去加载通过basePackages属性指定的包下面的，默认为扫描@Controller，@Service，@Component，@Repository注解的类。不指定basePackages则是类路径下面，或者如果使用注解@ComponentScan方式，则是当前类所在包及其子包下面。

2.基于配置类的spring配置

• 如果是基于配置类而不是基于applicationContext.xml来对spring进行配置，如SpringBoot，则在内部使用的IOC容器实现为AnnotationConfigApplicationContext或者其派生类，在AnnotationConfigApplicationContext内部会自动创建和激活以上的BeanPostProcessor。
• 如果同时存在基于xml的配置和配置类的配置，而在注入时间方面，基于注解的注入先于基于XML的注入，所以基于XML的注入会覆盖基于注解的注入。

总结

• @Autowired是Spring自带的，@Inject和@Resource都是JDK提供的，其中@Inject是JSR330规范实现的，@Resource是JSR250规范实现的，而Spring通过BeanPostProcessor来提供对JDK规范的支持。
• @Autowired、@Inject用法基本一样，不同之处为@Autowired有一个required属性，表示该注入是否是必须的，即如果为必须的，则如果找不到对应的bean，就无法注入，无法创建当前bean。
• @Autowired、@Inject是默认按照类型匹配的，@Resource是按照名称匹配的。如在spring-boot-data项目中自动生成的redisTemplate的bean，是需要通过byName来注入的。如果需要注入该默认的，则需要使用@Resource来注入，而不是@Autowired。
• 对于@Autowire和@Inject，如果同一类型存在多个bean实例，则需要指定注入的beanName。@Autowired和@Qualifier一起使用，@Inject和@Name一起使用。

 

4.缓存雪崩产生的原因
缓存雪崩通俗简单的理解就是：由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从Redis中获取，如下图）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。

Redis雪崩效应的解决方案
1、可以使用分布式锁   单机版的话本地锁
2、消息中间件方式
3、一级和二级缓存 Redis+Ehchache
4、均摊分配Redis的key的失效时间

5.kafka和RabbitMQ的区别

1、吞吐量
kafka吞吐量更高：
　　1）Zero Copy机制，内核copy数据直接copy到网络设备，不必经过内核到用户再到内核的copy，减小了copy次数和上下文切换次数，大大提高了效率。
　　2）磁盘顺序读写，减少了寻道等待的时间。
　　3）批量处理机制，服务端批量存储，客户端主动批量pull数据，消息处理效率高。
　　4）存储具有O(1)的复杂度，读物因为分区和segment，是O(log(n))的复杂度。
　　5）分区机制，有助于提高吞吐量。

2、可靠性
rabbitmq可靠性更好：
　　1）确认机制（生产者和exchange，消费者和队列）；
　　2）支持事务，但会造成阻塞；
　　3）委托（添加回调来处理发送失败的消息）和备份交换器（将发送失败的消息存下来后面再处理）机制；

3、高可用
　　1）rabbitmq采用mirror queue，即主从模式，数据是异步同步的，当消息过来，主从全部写完后，回ack，这样保障了数据的一致性。
　　2）每个分区都可以有一个或多个副本，这些副本保存在不同的broker上，broker信息存储在zookeeper上，当broker不可用会重新选举leader。
　　kafka支持同步负责消息和异步同步消息（有丢消息的可能），生产者从zk获取leader信息，发消息给leader，follower从leader pull数据然后回ack给leader。

4、负责均衡
　　1）kafka通过zk和分区机制实现：zk记录broker信息，生产者可以获取到并通过策略完成负载均衡；通过分区，投递消息到不同分区，消费者通过服务组完成均衡消费。
　　2）需要外部支持。

5、模型
　　1）rabbitmq：
　　　　producer，broker遵循AMQP（exchange，bind，queue），consumer；
　　　　broker为中心，exchange分topic，direct，fanout和header，路由模式适合多种场景；
　　　　consumer消费位置由broker通过确认机制保存；
　　2）kafka：
　　　　producer，broker，consumer，未遵循AMQP；
　　　　consumer为中心，获取消息模式由consumer自己决定；
　　　　offset保存在消费者这边，broker无状态；
　　　　消息是名义上的永久存储，每个parttition按segment保存自己的消息为文件（可配置清理周期）；
　　　　consumer可以通过重置offset消费历史消息；
　　　　需要绑定zk；