Java面试：2021.05.31

1、integer是否可以用==判断相等？

1. Ingeter是int的包装类，int的初值为0，Ingeter的初值为null。
2. 无论如何，Integer与new Integer()不会相等。不会经历拆箱过程，i8的引用指向堆，而i4指向专门存放他的内存（常量池），他们的内存地址不一样，使用 == 比较都为false。
3. 两个都是非new出来的Integer，使用 == 比较，如果数在-128到127之间，则是true，否则为false
4. 两个都是new出来的，==比较都为false。若要比较值是否相等，需使用equals方法进行比较。
5. int和Integer(无论new否)比，都为true，因为会把Integer自动拆箱为int再去比。

2、Integer 转 int 的时候有过哪些坑？

    SSM类型项目；

    实体类grade字段初始设定为int类型；

    用mybatis对第三条数据进行修改时，希望赋值的更改，未赋值的不更改，测试运行；

    修改后发现数据库中的grade字段变成了0，这不是我想要的，（按照正常需求应该是原来的数字5）；

   原因：int 类型，在默认情况下不赋值为0，执行到mybatis的更新语句时，被当做数字0，而非null。integer的默认值为null，即Integer可以区分出未赋值和值为0的区别，int则无法表达出未赋值的情况。

       总结：在实体类中尽量使用Integer修饰，Integer可以区分出未赋值和值为0的区别，我们大部分做判断都是以“”null“”去判断的。

3、Integer 包装类底层是怎么实现的？

概念：装箱就是自动将基本数据类型转换为包装器类型；拆箱就是自动将包装器类型转换为基本数据类型。

实现：装箱过程是通过调用包装器的valueOf方法实现的，而拆箱过程是通过调用包装器的 intValue方法实现的。

4、spring框架中都用到了那些设计模式？

代理模式 — 在 AOP 和 remoting 中被用的比较多。 

单例模式 — 在 Spring 配置文件中定义的 Bean 默认为单例模式。 

模板方法 — 用来解决代码重复的问题。比如 RestTemplate、JmsTemplate、JdbcTemplate 。 

前端控制器 — Spring提供了 DispatcherServlet 来对请求进行分发。 

视图帮助(View Helper) — Spring 提供了一系列的 JSP 标签，高效宏来辅助将分散的代码整合在视图里。 

依赖注入 — 贯穿于 BeanFactory / ApplicationContext 接口的核心理念。工厂模式 — BeanFactory 用来创建对象的实例。

还有其他的一些设计模式的体现。设计模式本身就是一种结构思想，在很多架构设计都均有应用和体现。另外，在回答这些问题的时候不妨谈谈自己对其的理解，在项目中的应用和实现。

5、spring  bean的生命周期？

图片

Spring Bean 的初始化流程如下：

图片

Spring Bean 的销毁流程如下：

图片

6、Spring 框架中的单例 Bean 是线程安全的吗？

Spring 框架并没有对单例 Bean 进行任何多线程的封装处理。 

关于单例 Bean 的线程安全和并发问题，需要开发者自行去搞定。 

并且，单例的线程安全问题，也不是 Spring 应该去关心的。Spring 应该做的是，提供根据配置，创建单例 Bean 或多例 Bean 的功能。

当然，但实际上，大部分的 Spring Bean 并没有可变的状态(比如Serview 类和 DAO 类)，所以在某种程度上说 Spring 的单例 Bean 是线程安全的。 

如果你的 Bean 有多种状态的话，就需要自行保证线程安全。浅显的解决办法，就是将多态 Bean 的作用域( Scope )由 Singleton 变更为 Prototype 。

7、如何在 Spring 中启动注解装配？

默认情况下，Spring 容器中未打开注解装配。因此，要使用基于注解装配，我们必须通过配置 <context：annotation-config /> 元素在 Spring 配置文件中启用它。 8、使用 Spring 事务有什么优点？

1.通过 PlatformTransactionManager ，为不同的数据层持久框架提供统一的 API ，无需关心到底是原生 JDBC、Spring JDBC、JPA、Hibernate 还是 MyBatis 。 

2.通过使用声明式事务，使业务代码和事务管理的逻辑分离，更加清晰。 

从倾向上来说，比较喜欢注解 + 声明式事务。

9、秒杀系统中如何防止超售？如何避免脚本进行恶意刷单？

防止超售解决方案：将存库从 MySQL 前移到 Redis 中，所有的写操作放到内存中， 由于 Redis 中不存在锁故不会出现互相等待，并且由于 Redis 的写性能和读性能都 远高于 MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变 化的数据异步写入到 DB 中。当达到库存阀值的时候就不在消费队列，并关闭购买功能。 

避免脚本恶意刷单：采用 IP 级别的限流，即针对某一个 IP，限制单位时间内发起请求数量。

10、当商品库存数量不足时，如何保证不会超卖？

当库存数量不足时，必须保证库存不能被减为负数，如果不加以控制，库存被减为小于等于 0的数， 那么这就叫做超卖。 那么如何防止超卖的现象发生呢？ 场景一：如果系统并发要求不是很高 那么此时库存就可以存储在数据库中，数据库中加锁控制库存的超卖现象。

图片

场景二：系统的并发量很大 如果系统并发量很大，那么就不能再使用数据库来进行减库存操作了，因为数据库加锁操作本身是 以损失数据库的性能来进行控制数据库数据的一致性的。 但是当并发量很大的时候，将会导致数据库排队，发生阻塞。因此必须使用一个高效的 nosql数据库 服务器来进行减库存。 此时可以使用 redis 服务器来存储库存，redis 是一个内存版的数据库，查询效率相当的高，可以使用 watch 来监控减库存的操作，一旦发现库存被减为 0，立马停止售卖操作。