各类题目答疑总结

songwei128

于 2015-01-27 13:09:59 发布

阅读量638

点赞数

分类专栏：答疑总结

本文链接：https://blog.csdn.net/songwei128/article/details/43193549

版权

答疑总结专栏收录该内容

1 篇文章 0 订阅

订阅专栏

各类题型答疑总结：

1、Spring底层如何实现单实例的？

Spring管理单实例的bean是通过单例注册表来实现的，而这个注册表的缓存是HashMap,如果要获取单实例的bean，那么首先会到单实例注册表缓存中查找，如果有则直接

返回该bean，否则创建该实例bean，添加到缓存中同时返回创建的bean，如果获取的是多实例的对象，那么直接到一般缓存中获取该对象返回。

2、Redis持久化机制？

1、Redis的第一个持久化策略：RDB快照

Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

我们可以通过Redis的save指令来配置RDB快照生成的时机，比如你可以配置当10分钟以内有100次写入就生成快照，也可以配置当1小时内有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。

同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。

但是，我们可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到 Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制：AOF日志。

2、Redis的第二个持久化策略：AOF日志

AOF日志的全称是Append Only File，从名字上我们就能看出来，它是一个追加写入的日志文件。与一般数据库不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。比如我们进行如下实验，使用Redis2.6 版本，在启动命令参数中设置开启AOF功能：

代码

./redis-server --appendonly yes

然后我们执行如下的命令：

代码

redis 127.0.0.1:6379> set key1 Hello
OK
redis 127.0.0.1:6379> append key1 " World!"
(integer) 12
redis 127.0.0.1:6379> del key1
(integer) 1
redis 127.0.0.1:6379> del non_existing_key
(integer) 0

这时我们查看AOF日志文件，就会得到如下内容：

代码

$ cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
key1
$5
Hello
*3
$6
append
$4
key1
$7
World!
*2
$3
del
$4
key1

可以看到，写操作都生成了一条相应的命令作为日志。 其中值得注意的是最后一个del命令，它并没有被记录在AOF日志中，这是因为Redis判断出这个命令不会对当前数据集做出修改。所以不需要记录这个无用的写命令。另外AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。

AOF重写

你可以会想，每一条写命令都生成一条日志，那么AOF文件是不是会很大？答案是肯定的，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。

注意： AOF重写核心是，如果一个AOF文件达到很大的时候，那么将这个大的AOF文件重新写到一个临时的aof文件中，并且会对一个值的操作只会记录一次，在写到新的aof文件的过程中，所有的写操作还会写到原来的老的AOF文件中，并且会记录到内存缓冲区中，当重写完成后，会将所有的缓存新数据写入到临时文件，然后原子性rename新的临时文件覆盖原来的旧的AOF文件。

3、Redis持久化性能？

从上面的流程我们能够看到，RDB是顺序IO操作，性能很高。而同时在通过RDB文件进行数据库恢复的时候，也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读取错误。

而AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的5个流程。那么写AOF的操作安全性又有多高呢？实际上这是可以设置的，在Redis中对AOF调用write写入后，何时再调用fsync将其写到磁盘上，通过appendfsync选项来控制，下面appendfsync的三个设置项，安全强度逐渐变强。

1、appendfsync no

当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

2、appendfsync everysec

当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。

所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。

这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。

3、appednfsync always

当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining 就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec 时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

4、Redis性能优化？

内存管理优化

Redis Hash是value内部为一个HashMap，如果该Map的成员数比较少，则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销，这个参数控制对应在redis.conf配置文件中下面2项：

hash-max-zipmap-entries 64 hash-max-zipmap-value 512

当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储，默认是64,即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的HashMap。

hash-max-zipmap-value 含义是当 value这个Map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。

以上2个条件任意一个条件超过设置值都会转换成真正的HashMap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，HashMap的优势就是查找和操作的时间复杂度都是O(1)的，而放弃Hash采用一维存储则是O(n)的时间复杂度，如果

成员数量很少，则影响不大，否则会严重影响性能，所以要权衡好这个值的设置，总体上还是最根本的时间成本和空间成本上的权衡。

list-max-ziplist-value 64 list-max-ziplist-entries 512

list数据类型节点值大小小于多少字节会采用紧凑存储格式、list数据类型多少节点以下会采用去指针的紧凑存储格式。

内存预分配：

Redis内部实现没有对内存分配方面做过多的优化（对比Memcache），在一定程度上会存在内存碎片，不过大多数情况下这个不会成为Redis的性能瓶颈，不过如果在Redis内部存储的大部分数据是数值型的话，Redis内部采用了一个shared integer的方式来省去分配内存的开销，即在系统启动时先分配一个从1~n 那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下，也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义REDIS_SHARED_INTEGERS，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。

持久化机制：

定时快照方式(snapshot)：

该持久化方式实际是在Redis内部一个定时器事件，每隔固定时间去检查当前数据发生的改变次数与时间是否满足配置的持久化触发的条件，如果满足则通过操作系统fork调用来创建出一个子进程，这个子进程默认会与父进程共享相同的地址空间，这时就可以通过子进程来遍历整个内存来进行存储操作，而主进程则仍然可以提供服务，当有写入时由操作系统按照内存页(page)为单位来进行copy-on-write保证父子进程之间不会互相影响。

该持久化的主要缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。

基于语句追加方式(aof)：

aof方式实际类似mysql的基于语句的binlog方式，即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是Redis的持久化数据。

aof的方式的主要缺点是追加log文件可能导致体积过大，当系统重启恢复数据时如果是aof的方式则加载数据会非常慢，几十G的数据可能需要几小时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写log,所以使用aof的方式，Redis的读写性能也会有所下降。

可以考虑将数据保存到不同的Redis实例中，每个实例的内存大小在2G左右，避免将鸡蛋放到一个篮子里，既可以减少缓存失效给系统带来的影响，又可以加快数据恢复的速度，不过同时也给系统设计带来了一定的复杂性。

Redis持久化崩溃问题：

有Redis线上运维经验的人会发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork 调用的copy-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般你的系统不会在短时间内所有的页都发生了写入而导致复制，那么是什么原因导致Redis崩溃的呢？

答案是Redis的持久化使用了Buffer IO造成的，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache,而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大(尤其是快照文件)，并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层Cache,而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做Page Cache的剔除工作，但内核很可能认为某块Page Cache更重要，而让你的进程开始Swap ,这时你的系统就会开始出现不稳定或者崩溃了。我们的经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。

总结：

根据业务需要选择合适的数据类型，并为不同的应用场景设置相应的紧凑存储参数。
当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能以及最大的内存使用量。
如果需要使用持久化，根据是否可以容忍重启丢失部分数据在快照方式与语句追加方式之间选择其一，不要使用虚拟内存以及diskstore方式。
不要让你的Redis所在机器物理内存使用超过实际内存总量的3/5。

redis.conf中的maxmemory选项，该选项是告诉Redis当使用了多少物理内存后就开始拒绝后续的写入请求，该参数能很好的保护好你的Redis不会因为使用了过多的物理内存而导致swap,最终严重影响性能甚至崩溃。

redis.conf文件中 vm-enabled 为 no.

5、redis虚拟内存vm

虚拟内存简述

Redis遵循一种Key-Value键值模型。你可以将键与一些值关联起来。通常情况下，Redis把键和相关联的值都存储在内存中，但有时候这未必是最佳选择。为了确保能够快速查找，键必须存储在内存中，但是可以把一些很少使用的值交换至磁盘中。

在实践过程中，如果你的内存中存有10w个键的数据集，但是只有10%的键是经常使用的，那么开启了虚拟内存机制的Redis就会把这些利用率不高的键所对应的值数据交换至磁盘中。

当客户端发起一条命令，请求访问这些冷门数据并作为结果返回的时候，这些值又会从交换文件中重新加载至内存中。

使用虚拟内存的时机

在你决定使用虚拟内存之前，你应该问自己是否真的需要这个特性。Redis只是一种用磁盘做备份的内存数据库。Redis的使用之道应该是尽可能的使用足够的内存以保证数据全部存放在内存中。但是下列场景中不是必须如此：

数据访问总是集中在某些数据上。只需要一小部分键就可以获得大部分的访问数据（例如你网站的活跃用户数据）。与此同时，每个键有太多数据存放在内存中。
可能因为没有过多考虑数据存储模式，或者数据值太大，使得我们没有足够的内存将所有的数据都存放在内存中。在这种环境下，Redis可以转化成只把键存放于内存中的磁盘数据库使用，这样键查询速度依然很快，但是在访问值的时候需要去读取低速的磁盘。

有一点非常值得注意，Redis无法将键交换至磁盘中，因此如果你的内存问题是因太多值很小的键引起，虚拟内存机制是帮不了你的。

但是，如果大部分内存开销都用于大容量的值存储时（例如很大的字符串，列表，集合或者很多元素的哈希），那么选用虚拟内存机制是一个好主意。

有时候，你可以通过采用Hash结构将相关数据分组存入到一个单键所对应的字段，把“大量值很小的键”情况所引发的问题，转化成“键很少但是值很大”的情况。举个例子，通过把一个对象的不同属性映射至一个单键的Hash字段上，来取代为对象的每个属性都使用一个键的方案。（思门注：Hash数据结构同样从Redis2.x版本开始出现）

虚拟内存配置

配置Redis的虚拟内存并不难，但是应该根据需求细心的设置最佳的参数。

虚拟内存的开启和配置都是通过编辑redis.conf文件实现，首先将它启用：

vm-enabled yes

有大量的选项可以改变虚拟内存的性能。如果不希望使用默认配置运行每个数据集，那么你需要做一些细微的调整以获取最大的性能

6、spring 依赖注入的原理分析总结：

一： IOC容器初始化

二：依赖注入的实现原理

三：AOP实现原理

http://blog.csdn.net/songwei128/article/details/43272009

7、递归遍历出树菜单结构

8、同一浏览器多窗口session问题

9、Spring中主要的设计模式

单例、工厂、策略、代理、模板方法、观察者、适配器等设计模式

10、HTTP长连接与短连接

一、什么是长连接
HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端-->代理-->服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端-->代理”连接和“代理-->服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多，很多时候代理是我们自己控制的，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理，常见的是客户端跟Nginx代理服务器使用HTTP1.1协议&长连接，而Nginx代理服务器跟后端服务器使用HTTP1.0协议&短连接。

在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection: Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。
以前使用libcurl做的上传/下载，就是短连接，抓包可以看到：1、每一条TCP通道只有一个POST；2、在数据传输完毕可以看到四次握手包。只要不调用curl_easy_cleanup，curl的handle就可能一直有效，可复用。这里说可能，因为连接是双方的，如果服务器那边关掉了，那么我客户端这边保留着也不能实现长连接。
如果是使用windows的WinHTTP库，则在POST/GET数据的时候，虽然我关闭了句柄，但这时候TCP连接并不会立即关闭，而是等一小会儿，这时候是WinHTTP库底层支持了跟Keep-alive所需要的功能：即便没有Keep-alive，WinHTTP库也可能会加上这种TCP通道复用的功能，而其它的网络库像libcurl则不会这么做。以前观察过WinHTTP库不会及时断开TCP连接。

二、长连接的过期时间
客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：

上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

三、长连接的数据传输完成识别
使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。更细节的介绍可以看这篇文章。

四、并发连接数的数量限制
在web开发中需要关注浏览器并发连接的数量，RFC文档说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩，知乎这里有分析，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。

五、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive
TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。
TCP keep alive的表现：
当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。
这个“一段时间”可以设置。
WinHttp库的设置：
WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.
libcurl的设置：
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html
CURLOPT_TCP_KEEPALIVE
Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).
CURLOPT_TCP_KEEPIDLE
Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)
CURLOPT_TCP_KEEPINTVL
Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT_TCP_KEEPIDLE是空闲多久发送一个心跳包，CURLOPT_TCP_KEEPINTVL是心跳包间隔多久发一个。
打开网页抓包，发送心跳包和关闭连接如下：
从上图可以看到，大概过了44秒，客户端发出了心跳包，服务器及时回应，本TCP连接继续保持。到了空闲60秒的时候，服务器主动发起FIN包，断开连接。

六、HTTP 流水线技术
使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指，在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining。
由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决）。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样。
在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源。
目前浏览器并不太重视这个技术，毕竟性能提升有限

11、Spring 的factorybean和普通bean的作用以及区别

Spring FactoryBean 是创建复杂的bean，一般的bean 直接用xml配置即可，如果一个bean的创建过程中涉及到很多其他的bean 和复杂的逻辑，用xml配置比较困难，这时可以考虑用FactoryBean 。

普通bean和bean工厂,即FactoryBean. FactoryBean 返回的不是这个类的实例，其返回的是该工厂Bean的getObject()方法所返回的对象普通的Bean直接返回指定类(配置中的class属性的值)的一个实例.

12、Spring MVC主要用到哪些设计模式

所知道的有适配器模式，将处理器是配成对应的adapter,然后可以处理不同类型的处理器，Command命令模式: HandlerExecutionChain, 这是典型的 Command 的模式的使用，这个执行链里面维护 handler 和拦截器

13、yield、wait、sleep的区别

我们知道，wait()的作用是让当前线程由“运行状态”进入“等待(阻塞)状态”的同时，也会释放同步锁。而yield()的作用是让步，它也会让当前线程离开“运行状态”。

      它们的区别是：
      (01) wait()是让线程由“运行状态”进入到“等待(阻塞)状态”，而不yield()是让线程由“运行状态”进入到“就绪状态”。
      (02) wait()是会线程释放它所持有对象的同步锁，而yield()方法不会释放锁。

我们知道，wait()的作用是让当前线程由“运行状态”进入“等待(阻塞)状态”的同时，也会释放同步锁。而sleep()的作用是也是让当前线程由“运行状态”进入到“休眠

(阻塞)状态”。但是，wait()会释放对象的同步锁，而sleep()则不会释放锁。

14、Maven如何解决依赖冲突

maven依赖冲突的产生是由maven传递性依赖造成的：

什么是maven传递依赖？
“一个传递性依赖就是对于一个依赖的依赖。如果project-a依赖于project-b，而后
者接着依赖于project-c，那么project-c就被认为是project-a的传递性依赖。如
果project-c依赖于project-d，那么project-d就也被认为是project-a的传递性依
赖。Maven的部分吸引力是由于它能够管理传递性依赖，并且能够帮助开发者屏蔽掉跟
踪所有编译期和运行期依赖的细节。你可以只依赖于一些包如Spring Framework，而不
用担心Spring Framework的所有依赖，Maven帮你自动管理了，你不用自己去详细了解
配置。
Maven是怎样完成这件事情的呢？它建立一个依赖图，并且处理一些可能发生的冲突和
重叠。例如，如果Maven看到有两个项目依赖于同样的groupId和artifactId，它会自动
整理出使用哪个依赖，选择那个最新版本的依赖。虽然这听起来很方便，但在一些边界
情况中，传递性依赖会造成一些配置问题。在这种情况下，你可以使用依赖排除。”
——摘自《Maven权威指南》

什么情况下会产生依赖冲突？
举例说明：项目中的pom.xml里声明了对project-a1.0与project-b2.0的依赖，而project-a1.0又传递依赖于project-b1.0的版本。
假设maven经过分析之后决定使用project-b1.0的依赖，也就是打包的时候把project-b1.0.jar打进了war包。
war包部署在java容器中启动之后，如果依赖project-b2.0.jar中新添的类或方法，就会发现引用的类或者方法不存在。
这种现象就是依赖冲突。

如何分析依赖冲突？
mvn dependency:tree

冲突解决方案：
使用maven提供的<exclusion>标签。
举例说明：
如果你正依赖于一个类库，该类库又依赖于Sun JTA API，你会想要替换这个传递性依赖。
Hibernate是一个例子。Hibernate依赖于Sun JTA API，而后者在中央Maven仓库中不可用，因为它是不
能免费分发的。幸运的是，Apache Gernoimo项目创建了一些可以免费分发的独立实现
类库。为了用另外的依赖来替换这个传递性依赖，你需要排除这个传递性以依赖，然后
在你的项目中再声明一个依赖。下面展示了这样一个替换的样例。