java面试题8

081. Spring 如何处理线程并发问题

在一般情况下，只有无状态的 Bean 才可以在多线程环境下共享，在 Spring 中，绝大部分 Bean 都可以声明为singleton 作用域，因为 Spring 对一些 Bean 中非线程安全状态采用 ThreadLocal 进行处理，解决线程安全问题。

ThreadLocal 会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。

082. @Autowired 和@Resource 之间的区别

(1) @Autowired 默认是按照类型装配注入的，默认情况下它要求依赖对象必须存在（可以设置它 required 属性 为 false）。

(2) @Resource 默认是按照名称来装配注入的，只有当找不到与名称匹配的 bean 才会按照类型来装配注入。

083. spring 事务传播特性

 （1）propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，

这是 Spring 默认的选择。

（2）propagation_supports：支持当前事务，如果没有当前事务，就以非事务方法执行。

（3）propagation_mandatory：使用当前事务，如果没有当前事务，就抛出异常。

（4）propagation_required_new：新建事务，如果当前存在事务，把当前事务挂起。

084. springMVC 工作原理

1、 用户发送请求至前端控制器 DispatcherServlet。

2、 DispatcherServlet 收到请求调用 HandlerMapping 处理器映射器。

3、 处理器映射器找到具体的处理器(可以根据 xml 配置、注解进行查找)，生成处理器对

象及处理器拦截器(如果有则生成)一并返回给 DispatcherServlet。

4、 DispatcherServlet 调用 HandlerAdapter 处理器适配器。

5、 HandlerAdapter 经过适配调用具体的处理器(Controller，也叫后端控制器)。

6、 Controller 执行完成返回 ModelAndView。

7、 HandlerAdapter 将 controller 执行结果 ModelAndView 返回给 DispatcherServlet。

8、 DispatcherServlet 将 ModelAndView 传给 ViewReslover 视图解析器。

9、 ViewReslover 解析后返回具体 View。

10、DispatcherServlet 根据 View 进行渲染视图（即将模型数据填充至视图中）。

11、 DispatcherServlet 响应用户。

085. springMVC 的常用注解

@requestMapping: 请求路径映射处理方法

@responseBody:响应数据为 json 数据

@requestBody:接收 json 数据，反序列化为 java 对象

@pathVariable:接收 restful 风格的参数，参数在 url 路径中，需要通过该注解获取参数

@ModelAttribute:将数据保存到 request 域中  

@RequestParam:接收参数

086:@PathViable和@RequestParam的区别

  @PathViable获取的是拼接请求路径中的参数，必须显示使用,@RequestParam获取?传递的参数，默认使用.

087:在springMVC中ResponseBody和RequestBody的作用

一般的控制器方法返回的内容都是表示一个视图资源，由视图解析器进行数据分析，如果方法使用了@ResponseBody标识则该方法返回的是json数据不会返回页面。

RequestBody用于把前台页面提交的JSON参数，转换为一个对象参数

088. 过滤器和拦截器的区别

执行顺序 ：过滤前 - 拦截前 - Action 处理 - 拦截后 - 过滤后。

1、拦截器是基于 java 的反射机制的，而过滤器是基于函数回调。

2、拦截器不依赖与 servlet 容器，过滤器依赖与 servlet 容器。

3、拦截器只能对处理器(Controller、Action)请求起作用，而过滤器则可以对几乎所有的请求起作用。

4、拦截器可以访问上下文对象，而过滤器不能访问。

5、在 Servlet 的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次

089.什么是 dubbo

Dubbo 是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，之前是阿里巴巴内部孵化，想在阿里内部大范围推广使用，结果淘宝网有一个已经在 2000 个应用中使用的 HSF(好舒服)，于是 dubbo 开源，但是 12 年 10 月份[2.5.3]后停止维护，结果公司应用比较广泛，后来当当网还在 dubbo 的基础上，开发了个 dubbox的框架，看到市场这么火，阿里官方团队，17 年又开始正式维护 dubbo 项目，对 dubbo 进行维护和更新。现已成为 Apache 基金会孵化项目。

090.为什么使用 dubbo（或者RPC的几种实现方式）

1 webService 进行系统通讯，比如运营商或者传统项目，优点是跨平台跨语言，缺点是比较臃肿，学习成本高，交互数据是 XML，传输和解析效率低，新版本 json 也可以交互；

2使用 http+json 的方式进行交互，相对来说，学习成本低，效率比 webService高，也是跨平台跨语言。 但是随着业务的发展，http 的 rest 接口管理和安全问题、效率问题随着系统和用户的增长，都日益凸显，因为 json 数据需要经历序列化-反序列化-序列化-反序列化的交互工程，效率相对来说还是比较低。

3 dubbo 是阿里开源项目。内部使用了 Netty、Zookeeper， 保证了高性能高可用性。dubbo的 RPC 通信非常透明，用户感觉就像调用本地方法一样调用远程方法，非常方便。相当于 A 系统要调用 B 系统中的方法，方法在 B 系统执行，但是通过 RPC 通信，就仿佛是在 A 系统 执行一样，用户只需要访问 A 系统时传递给 A 系统，调用 B 系统方法需要的参数，A 系统就会底层通过 TCP 协议，将 B 系统方法需要的参数传递过去，执行方法，执行后将结果返回给 A 系统，用户感知不到 A、B 系统通讯的过程，感觉就是 A 系统执行的方法一样。

更多面试题，在我主页，java面试分栏