2018java程序员面试题整理
[email protected]注解和@RequestParam注解的区别。
@RequestParam注解是获取静态URL传入的参数
@PathVariable是获取请求路径中的变量作为参数
/需要和@RequestMapping("item/{itemId}") 配合使用
[email protected]注解和@RequestParam注解的区别。
@Parm 指定request中必须包含某些参数值是，才让该方法处理。
注意@RequestMapping(value = "test", params = { "username","age!=10" })
@param一般标注在xxxmapper.Java文件中的 参数位置，代表给传入的参数别名，一般用在传入多个参数的时候，在xml文件中使用sql语句通过占#{} ${}占位符来获取
#{}防止sql注入
@RequestParam value 请求的参数 defaultvalue
1.request.getParameter(“参数名”)
2.用@RequestParam注解获取
3.Servlet标准中的过滤器：Filter和SpringMVC中的拦截器：Interceptor有什么异同？
Filter：
在HttpServletRequest到达Servlet之前，拦截客户的HttpServletRequest。
根据需要检查HttpServletRequest，也可以修改HttpServletRequest头和数据。
在HttpServletResponse到达客户端之前，拦截HttpServletResponse。
根据需要检查HttpServletResponse，也可以修改HttpServletResponse头和数据。
两者的本质区别：
1、拦截器是基于java的反射机制的，而过滤器是基于函数回调
2、过滤器依赖与servlet容器，而拦截器不依赖与servlet容器依赖spring容器
3、拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用
4、拦截器可以访问action上下文、值栈里的对象，而过滤器不能
5、在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次
执行顺序 ：过滤前 - 拦截前 - Action处理 - 拦截后 - 过滤后。
拦截器有前置/后置/完成三个方法，在没有执行到处理器（controller）时不会只执行任何拦截器 比如我controller没有/user路径
多个执行顺序 前1前2前3后3后2后1 完3 完2 完1
2 return false 前 1 前 2 完1
（拦截了没有到达处理器，都不会触发后置）
前置方法为true时必定有完成方法
4. 在Mybatis环境中如何在SQL语句中引用接口方法传入的参数？
一. 用Map，在方法体里，我们把多个参数存放在map里，然后在前面获得它
二. 用ibatis中的@Param
5. 在Mybatis环境中如何在SQL语句中引用接口方法传入的参数？
一. 用Map，在方法体里，我们把多个参数存放在map里，然后在前面获得它
二. 用ibatis中的@Param
6.请介绍一下Maven依赖关系中的传递性现象。有什么限制。
依赖是可以往下传递的；A依赖B；B工程依赖的其他模块，A都可以使用；
调整依赖的传递规则：
1）、调整jar的依赖范围：
默认：compile，依赖是传递的；非compile范围的依赖不能传递；
2）、设置这个jar是可选的；
<!-- 这个依赖是可选的；默认不传递下来 -->
<optional>true</optional>
3）、排除依赖：
<exclusions>
<!-- 排除依赖 -->
<exclusion>
<artifactId>log4j</artifactId>
<groupId>log4j</groupId>
</exclusion>
</exclusions>
7.请介绍一下Maven依赖范围中compile、test、provided这三种情况。
<!--compile：指：在编译运行测试期间都可以使用这个jar，打包的时候会带上这个jar -->
<!--test:主程序编译的时候不通过，测试可以使用，打包不带这个jar -->
<!--provided:(已提供) ：基本和compile是一样的，只是打包的时候不带 -->
8.请介绍一下 Quartz 石英调度技术的使用方法，你在项目中是如何使用的？Job：任务（我们需要完成的事情）；【要炸大本营】
JobDetail：任务详情（任务怎么做，谁来做）；
【执行任务需要的对象，数据信息等】【张三，50吨TNT】
quartz：为了并发执行；
Job（定义任务怎么执行的类）---JobDetail（当次执行的实例）；
Trigger：触发器；用来执行任务的；【炸药的引信】
Scheduler：调度器；调度任务；【帮我们在指定时间触发trigger】【中控台】
scheduler.scheduleJob(job, trigger);
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
</dependency>
有配置版和注解版 建议使用注解版
9请介绍一下事务的并发问题和隔离级别。
在关系型数据库中，事务的隔离性分为四个隔离级别，在解读这四个级别前先介绍几个关于读数据的概念。
1）脏读（Dirty Reads）：所谓脏读就是对脏数据（Drity Data）的读取，而脏数据所指的就是未提交的数据。也就是说，一个事务正在对一条记录做修改，在这个事务完成并提交之前，这条数据是处于待定状态的（可能提交也可能回滚），这时，第二个事务来读取这条没有提交的数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被称为脏读。
2）不可重复读（Non-Repeatable Reads）：一个事务先后读取同一条记录，但两次读取的数据不同，我们称之为不可重复读。也就是说，这个事务在两次读取之间该数据被其它事务所修改。
3）幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为幻读。
事务四个隔离级别对比： 隔离级别低，查询效率高
1）读未提交（Read Uncommitted）：SELECT语句以非锁定方式被执行，所以有可能读到脏数据，隔离级别最低。
2）读已提交（Read Committed）：只能读取到已经提交的数据。即解决了脏读，但未解决不可重复读。
3）可重复读（Repeated Read）：在同一个事务内的查询都是事务开始时刻一致的，InnoDB的默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻读。
4）串行话（Serializable）：完全的串行化读，所有SELECT语句都被隐式的转换成SELECT ... LOCK IN SHARE MODE，即读取使用表级共享锁，读写相互都会阻塞。隔离级别最高。
Mysql 四种都支持 默认可重复读
Oracle 支持串行化和读已提交
10.请说说你对事务传播行为的理解。
1： PROPAGATION_REQUIRED 默认的
假如当前正要执行的事务不在另外一个事务里，那么就起一个新的事务
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部，就不再起新的事务。 而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚
2： PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行这就跟平常用的普通非事务的代码只有一点点区别了。不理这个，因为我也没有觉得有什么区别
3： PROPAGATION_REQUIRES_NEW
这个就比较绕口了。比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，他才继续执行。
他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。
其余的事务一百年可能遇见一次