一些小问题记录
1、maven打包，provided
直接在war包所在项目设置<scope>provided</scope>可以保证该包最终不会被打包到war中。
如果不显示指定指定provided，有可能在依赖的第三方jar中间接依赖了该jar，从而隐形的将该包引进。
2、权限管理，缓存
在做权限控制时，每次都要对请求的url做拦截，然后根据用户的角色查询数据库看该用户有无访问该url的权限。
弊端：每访问一个url都要访问数据库，太耗性能了。
shrio框架的做法是将用户的权限缓存在ehcache中，每次权限检查只需要从缓存中取就可以取就可以了。
在没有用shiro框架的时候，我们也可以将权限存在缓存中，每次直接根据角色从缓存中取。（emmm... 实现貌似挺容易。但是从来没想过这样做）
shiro权限管理（选看）
自行实现权限拦截器，可以指定对哪些url使用哪些拦截器。角色拦截器，权限拦截器，在首次权限拦截的时候，将该登录用户角色及权限存入缓存。权限配置
依次要经过login，role，perms拦截器。很神奇的一点，举例，普通用户实际没有用户管理的权限（数据库没有），但若配置role[普通用户]，再以普通用户的角色访问拦截用户管理url，shiro也会放行，不会去查数据库实际是否拥有该权限，只要有该角色即可。
由此可见，shiro是将角色与url访问权限、模块权限与url访问权限分开管理（e.g. 具有用户管理模块权限的用户可以访问所有/user/**的url，这样，在数据库不用将每个url权限都与角色关联一遍，只需要关联某模块的权限，再针对某url组分配权限即可），角色拦截器只验证用户是否持有有效角色。权限拦截器只验证用户是否持有有效权限。
3、字的概念
计算机进行数据处理时，一次存取、加工和传送的数据长度称为字（word）。一个字通常由一个或多个（一般是字节的整数位）字节构成。例如286微机的字由2个字节组成，它的字长为16；486微机的字由4个字节组成，它的字长为32位机。
计算机的字长决定了其CPU一次操作处理实际位数的多少，由此可见计算机的字长越大，其性能越优越。
计算机的字长决定了其CPU一次操作处理实际位数的多少，由此可见计算机的字长越大，其性能越优越。
4、java的transient关键字
被transient关键字修饰的变量不会被序列化。
1）一旦变量被transient修饰，变量将不再是对象持久化的一部分，该变量内容在序列化后无法获得访问。
2）transient关键字只能修饰变量，而不能修饰方法和类。注意，本地变量是不能被transient关键字修饰的。变量如果是用户自定义类变量，则该类需要实现Serializable接口。
3）被transient关键字修饰的变量不再能被序列化，一个静态变量不管是否被transient修饰，均不能被序列化。
参考：https://www.cnblogs.com/lanxuezaipiao/p/3369962.html
5、FactoryBean、AutowireCapableBeanFactory
（1）、Scheduler注入问题
在学习定时任务的Quartz时，看到了下图，Scheduler被注入(Scheduler属于Quartz框架下的类)，但是在整个项目中都没有找到让Scheduler受Spring管理的配置。
于是找到对SchedulerFactoryBean
进入SchedulerFactoryBean中，实现了FactoryBean。如果一个类实现了FactoryBean接口，那么getBean得到的不是他本身，而是它所产生的对象（getObject()），如果我们希望得到它本身，只需要加上&符号即可。看下图可知虽然将SchedulerFactoryBean配置在xml，但是其产生的是Scheduler对象，因此是可以注入Scheduler。
（2）、Job中的Bean无法注入
最开始直接这样写，未进行任何配置，发现Job中的Bean无法被注入。原因是由于Quartz中框架中的Job不受Spring的管理，因此其也无法注入其他的Bean。解决该问题即使Job受Spring的管理。具体如下：
Job是由JobFactory产生的，该Factory不同于SchedulerFactoryBean，并未整合Spring，未实现FactoryBean，完全是一个第三方的类，不能通过SchedulerFactoryBean的方式解决。
项目做法是，自己实现了一个JobFactory，在JobFactory内部让其产生的Job受Spring管理，并在SchedulerFactoryBean中使用我们自己实现的JobFactory。AutowireCapableBeanFactory可以让不受Spring管理的类具有自动注入的功能