- 1.jvm内存模型
- 2.类的加载过程
- 3.gc可达性分析
- 4.gc常用算法
- 5.gc回收器
- 6.双亲委派模型
- 1.Arraylist源码解析,重点初始化,扩容机制,底层数据结构
- 2.Hashmap源码解析,重点初始化,哈希冲突,扩容,jdk1.7和1.8差异
- 3. ConcurrentHashmap源码解析,重点初始化,扩容,线程安全
- 1.线程的创建方式,至少4种
- 2.线程状态,和之间的相互切换
- 3.线程的常用方法。比如join wait sleep等
- 4.线程池七大参数
- 5.线程池工作流程
- 6.线程池的状态
- 1.synchronized用法
- 2.Java中锁的四种状态
- 3.synchronized底层实现过程
- 4.synchronized和lock区别
- 1.CAS和ABA的问题
- 2.Threadlocal的实现原理
- 3.什么是AQS
- 4.volitate的作用
- 5.线程池的五大状态
- 1.tcp的三次握手
- 2.tcp的四次挥手
- TCP的三次握手与四次挥手理解及面试题(很全面)">TCP的三次握手与四次挥手理解及面试题(很全面)
- 3.lambda表达式
- 4.反射的理解
- 5.自定义注解的作用
- 1.Cookie和Session的区别
- 2.Mysql的存储引擎的区别
- 3.on having where的区别
- 4.索引的数据结构B+Tree
- 5.索引的分类,聚簇索引,覆盖索引,联合索引,最左匹配
- 1.servlet生命周期
- 2.事务的理解
- 3.事务隔离级别
- 4.Spring的事务传播行为
- ">
- 1.spring循环依赖产生和解决
- 2.谈谈对ioc和di的理解
- 3.请说出spring bean的生命周期
- 4.aop的理解
- 5.spring中的设计模式
- 1.SpringBoot的自动装配原理
- 2.SpringMVC的运行流程
- SpringMVC的工作原理图:
- SpringMVC流程
- 组件说明:
- 核心架构的具体流程步骤如下:
- 在将SpringMVC之前我们先来看一下什么是MVC模式
- springMVC是什么:
- 3.SpringMVC的常用注解和意义
- 1、@Controller
- 2、@RequestMapping
- 3、@Resource和@Autowired
- 4、@ModelAttribute和 @SessionAttributes
- 5、@PathVariable
- 6、@requestParam
- 7、@ResponseBody
- 8、@Component
- 9、@Repository
- 将传入的数据都当成一个字符串,会对自动传入的数据加一个双引号。如:order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by “111”, 如果传入的值是id,则解析成的sql为order by “id”.
2. $将传入的数据直接显示生成在sql中。如:order by $user_id$,如果传入的值是111,那么解析成sql时的值为order by user_id, 如果传入的值是id,则解析成的sql为order by id.
3. #方式能够很大程度防止sql注入。
4.$方式无法防止Sql注入。
5.$方式一般用于传入数据库对象,例如传入表名.
6.一般能用#的就别用$.
MyBatis排序时使用order by 动态参数时需要注意,用$而不是
1.jvm内存模型
2.类的加载过程
3.gc可达性分析
4.gc常用算法
5.gc回收器
6.双亲委派模型
1.Arraylist源码解析,重点初始化,扩容机制,底层数据结构
ArrayList底层数据结构
transient Object[] elementData; // 用于存储数据的buffer数组
1
在 ArrayList集合的底层是由一个可变的动态 Object[]数组组成的,由于他是由数组构成的,所以该集合类框架对于随机访问的效率很高,时间复杂度为 O(1)。
public boolean add(E e) {<br /> modCount++;// 结构更改次数<br /> add(e, elementData, size);// 套娃<br /> return true;<br /> }<br /> private void add(E e, Object[] elementData, int s) {<br /> if (s == elementData.length)<br /> elementData = grow();// 自动扩容<br /> elementData[s] = e;// 在数组的末尾插入元素<br /> size = s + 1;<br /> }<br />但是在插入元素的时候,如果采用默认的 add(E e)便会在数组的末端插入,时间复杂度近似为 O(1)
public void add(int index, E element) {<br /> rangeCheckForAdd(index);// index校验<br /> modCount++;// 结构更改次数<br /> final int s;<br /> Object[] elementData;<br />// 当size 与 数组的容量一致,执行自动扩容<br /> if ((s = size) == (elementData = this.elementData).length)<br /> elementData = grow();// 扩容<br /> System.arraycopy(elementData, index,<br /> elementData, index + 1,<br /> s - index);// 数组元素往后移动一位,腾出桶位给待插元素<br /> elementData[index] = element;<br /> size = s + 1;<br /> }
如果在数组中间插入一个元素,那么他会先将该位置后面的元素整体往后移动一位后,再把待插入元素插入,这时的时间复杂度就近似为 O(n)。
线程不安全
纵观 ArrayLis的源码,所有的方法均没有进行线程安全方面的设计,故可见他是一个线程不安全的集合,与之相对应的就是 Vector,该集合框架,他就是一个线程安全的,对其内部每一个方法均进行线程安全的控制。根据以上的一些信息我们可以得出:在单线程的情况下,我们使用 ArrayList的效率会比 Vector高很多,但是在多线程的情况下,使用 ArrayList会有线程不安全的风险。
扩容机制
在 ArrayList中,其扩容的方法主要为 grow()方法:
我们进入内部:
private Object[] grow() {
return grow(size + 1);
}
我们发现他其实是一个套娃的方法:
private Object[] grow(int minCapacity) {
return elementData = Arrays.copyOf(elementData,
newCapacity(minCapacity));
}
其实到这里我们即可看出一点猫腻了, 用于储存数据的数组会被复制给另外一个数组,并把另一个数组的引用赋值给 elementData,而新数组的大小就是扩容后 elementData数组的大小,这个大小由方法 :newCapacity(int minCapacity)确定。
private int newCapacity(int minCapacity) {
// overflow-conscious code
int oldCapacity = elementData.length;
int newCapacity = oldCapacity + (oldCapacity >> 1);// 1.5 倍扩容
if (newCapacity - minCapacity <= 0) {
if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA)
return Math.max(DEFAULT_CAPACITY, minCapacity);
if (minCapacity < 0) // overflow,该值过大,超过了 int 的表示范围,为负数
throw new OutOfMemoryError();
return minCapacity;
}
return (newCapacity - MAX_ARRAY_SIZE <= 0) //当newCapacity>MAX_ARRAY_SIZE时,返回 hugeCapacity
? newCapacity
: hugeCapacity(minCapacity);
}
看到这里我们神秘的扩容机制将不再神秘了,细细分析,其实核心的还是最后一个 return语句:
return (newCapacity - MAX_ARRAY_SIZE <= 0) //当newCapacity>MAX_ARRAY_SIZE时,返回 hugeCapacity
? newCapacity
: hugeCapacity(minCapacity);
现在,newCapacity = 1.5*oldCapacity,它和定义的最大的数组大小 MAX_ARRAY_SIZE进行比较,如果小于,则返回 newCapacity进行扩容,否则调用 hugeCapacity(int minCapacity)
private static int hugeCapacity(int minCapacity) {
if (minCapacity < 0) // overflow
throw new OutOfMemoryError();
return (minCapacity > MAX_ARRAY_SIZE)
? Integer.MAX_VALUE
: MAX_ARRAY_SIZE;
}
很容易看出:当给定的最小容量 minCapacity比最大的数组大小大的时候,返回 int所能表达的最大整数 Integer.MAX_VALUE,否则,返回最大数组大小 MAX_ARRAY_SIZE。到此, ArrayList的扩容机制,基本就搞清楚了。
我们来总结一下:
变量说明:
newCapacity:新计算的扩容大小
minCapacity:最小的所需数组大小
MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8 :最大的数组大小(不同的 JVM在数组的处理上,可能会有头字符,所以预留了8个位置)
针对 ArrayList而言,会在往集合中添加元素的时候进入到扩容入口函数 grow(),当当前集合中的元素数量与存储数组的长度一样的时候,会触发扩容机制,会把当前数组的长度 + 1 作为扩容判断的标准,并计算出新的大小 newCapacity(约为当前数组长度的1.5倍),主要分为以下几种情况:
newCapacity <= minCapacity,判断当前的数组是否为默认的空数组,如果是,就返回默认初始化大小值(10)与 minCapacity中大的作为实际的扩容大小;否则直接返回 minCapacity。
如果 newCapacity不超过最大数组大小 MAX_ARRAY_SIZE,直接返回 newCapacity作为扩容大小,否则,用 minCapacity和 MAX_ARRAY_SIZE比较,如果不超过MAX_ARRAY_SIZE,则返回MAX_ARRAY_SIZE作为扩容大小;否则返回 Integer.MAX_VALUE作为扩容大小。
总之,在一般的情况下,基本都是以近乎于原数组大小的1.5倍扩容。
[
](https://blog.csdn.net/qq_45744501/article/details/107729024)
2.Hashmap源码解析,重点初始化,哈希冲突,扩容,jdk1.7和1.8差异
3. ConcurrentHashmap源码解析,重点初始化,扩容,线程安全
1.线程的创建方式,至少4种
Java使用Thread类代表线程,所有的线程对象都必须是Thread类或其子类的实例。Java可以用四种方式来创建线程,如下所示:
1)继承Thread类创建线程<br /> 通过继承Thread类来创建并启动多线程的一般步骤如下
1】d定义Thread类的子类,并重写该类的run()方法,该方法的方法体就是线程需要完成的任务,run()方法也称为线程执行体。
2】创建Thread子类的实例,也就是创建了线程对象
3】启动线程,即调用线程的start()方法
2)实现Runnable接口创建线程<br /> 通过实现Runnable接口创建并启动线程一般步骤如下:
1】定义Runnable接口的实现类,一样要重写run()方法,这个run()方法和Thread中的run()方法一样是线程的执行体
2】创建Runnable实现类的实例,并用这个实例作为Thread的target来创建Thread对象,这个Thread对象才是真正的线程对象
3】第三部依然是通过调用线程对象的start()方法来启动线程
3)使用Callable和Future创建线程<br /> 1】创建Callable接口的实现类,并实现call()方法,然后创建该实现类的实例(从java8开始可以直接使用Lambda表达式创建Callable对象)。
2】使用FutureTask类来包装Callable对象,该FutureTask对象封装了Callable对象的call()方法的返回值
3】使用FutureTask对象作为Thread对象的target创建并启动线程(因为FutureTask实现了Runnable接口)
4】调用FutureTask对象的get()方法来获得子线程执行结束后的返回值
4)使用线程池例如用Executor框架<br /> 1.5后引入的Executor框架的最大优点是把任务的提交和执行解耦。要执行任务的人只需把Task描述清楚,然后提交即可。<br /> 这个Task是怎么被执行的,被谁执行的,什么时候执行的,提交的人就不用关心了。具体点讲,提交一个Callable对象给ExecutorService(如<br /> 最常用的线程池ThreadPoolExecutor),将得到一个Future对象,调用Future对象的get方法等待执行结果就好了。Executor框架的内部使用<br /> 了线程池机制,它在java.util.cocurrent 包下,通过该框架来控制线程的启动、执行和关闭,可以简化并发编程的操作。因此,在Java 5之后,<br /> 通过Executor来启动线程比使用Thread的start方法更好,除了更易管理,效率更好(用线程池实现,节约开销)外,还有关键的一点:有助于<br /> 避免this逃逸问题——如果我们在构造器中启动一个线程,因为另一个任务可能会在构造器结束之前开始执行,此时可能会访问到初始化了一<br /> 半的对象用Executor在构造器中。
2.线程状态,和之间的相互切换
1、创建状态<br /> 使用 new 关键字和 Thread 类或其子类建立一个线程对象后,该线程对象就处于新建状态。它保持这个状态直到程序 start() 这个线程。<br /> 2、就绪状态<br /> 当线程对象调用了start()方法之后,该线程就进入就绪状态。就绪状态的线程处于就绪队列中,要等待JVM里线程调度器的调度。<br /> 3、运行状态<br /> 如果就绪状态的线程获取 CPU 资源,就可以执行 run(),此时线程便处于运行状态。处于运行状态的线程最为复杂,它可以变为阻塞状态、就绪状态和死亡状态。<br /> 4、堵塞状态<br /> 如果一个线程执行了sleep(睡眠)、suspend(挂起)等方法,失去所占用资源之后,该线程就从运行状态进入阻塞状态。在睡眠时间已到或获得设备资源后可以重新进入就绪状态。<br /> 可以分为三种:<br /> 等待阻塞:运行状态中的线程执行 wait() 方法,使线程进入到等待阻塞状态。<br /> 同步阻塞:线程在获取 synchronized同步锁失败(因为同步锁被其他线程占用)。<br /> 其他阻塞:通过调用线程的 sleep() 或 join() 发出了 I/O请求时,线程就会进入到阻塞状态。当sleep() 状态超时,join() 等待线程终止或超时,或者 I/O 处理完毕,线程重新转入就绪状态。<br /> 5、死亡状态<br /> 一个运行状态的线程完成任务或者其他终止条件发生时,该线程就切换到终止状态。
3.线程的常用方法。比如join wait sleep等
1.线程休眠sleep();:线程有优先级,但是我们可以用此方法人为的改变它们的优先级,让线程暂停,它其他线程获得分配空间。 <br /> 用法:Thread.sleep(2000);//休眠两秒 <br /> 2.线程让步yield();就是让出自己的分配空间给其他线程,那么问题来了,让步多久呢?如果有两条线程的话,是不是让步到另外一条线程执行完呢?经测试,不是让另外的线程执行,让步时间是不确定的; <br /> 注意:当某个线程调用yield()方法之后,只有与当前线程优先级形同或者更高的才能获得执行机会。 (直接进入可运行状态,有可能调用完自己又被CPU调度到,又直接变成运行状态了。)<br /> 用法:一般都是指定条件,如if(i==10){Thread.yield();} <br /> 3.线程插队join():当某个程序调用其他线程的join()时,调用线程将会阻塞,直到插入的线程运行完毕,才运行该线程,如main线程中for(int i = 0; i < 100; i++){if(i == 2){t.join();}},当i等于2时,线程t将执行完毕再执行main中余下的 i= 3i=4 …… <br /> 用法:一般都是指定条件,如if(i==10){t.join();}注意插队肯定是在别的线程中插别人的队,不可能在自己的线程中写join(); 如:t线程中写t.join();,这种方法是不正确的。 <br /> 4.wait():当前线程放弃同步锁进入等待状态,直到其他线程进入此同步锁notify()或notifyAll()唤醒线程为止。 <br /> 5.notify():唤醒锁上等待的第一个调用wait()方法的线程。 <br /> 6.notifyAll():唤醒同步锁上调用wait()的所有线程。 <br /> 注意:wait()、notify()、notifyAll()必须是同步锁对象。
4.线程池七大参数
(1)corePoolSize:线程池中常驻核心线程数
(2)maximumPoolSize:线程池能够容纳同时执行的最大线程数,此值必须大于等于1
(3)keepAliveTime:多余的空闲线程存活时间。当前线程池数量超过corePoolSize时,当空闲时间到达keepAliveTime值时,多余空闲线程会被销毁直到只剩下corePoolSize个线程为止。
(4)unit:keepAliveTime的时间单位
(5)workQueue:任务队列,被提交但尚未执行的任务
(6)threadFactory:表示生成线程池中的工作线程的线程工厂,用于创建线程,一般为默认线程工厂即可
(7)handler:拒绝策略,表示当队列满了并且工作线程大于等于线程池的最大线程数(maximumPoolSize)时如何来拒绝来请求的Runnable的策略<br /> AbortPolicy:为线程池默认的拒绝策略,该策略直接抛异常处理。<br /> DiscardPolicy:直接抛弃不处理。<br /> DiscardOldestPolicy:丢弃队列中最老的任务。<br /> CallerRunsPolicy:将任务分配给当前执行execute方法线程来处理。
5.线程池工作流程
1 当一个任务通过submit或者execute方法提交到线程池的时候,如果当前池中线程数(包括闲置线程)小于corePoolSize,则创建一个线程执行该任务。
2 如果当前线程池中线程数已经达到corePoolSize,则将任务放入等待队列。
3 如果任务不能入队,说明等待队列已满,若当前池中线程数小于maximumPoolSize,则创建一个临时线程(非核心线程)执行该任务。
4 如果当前池中线程数已经等于maximumPoolSize,此时无法执行该任务,根据拒绝执行策略处理。
注意:当池中线程数大于corePoolSize,超过keepAliveTime时间的闲置线程会被回收掉。回收的是非核心线程,核心线程一般是不会回收的。如果设置allowCoreThreadTimeOut(true),则核心线程在闲置keepAliveTime时间后也会被回收。
任务队列是一个阻塞队列,线程执行完任务后会去队列取任务来执行,如果队列为空,线程就会阻塞,直到取到任务。
6.线程池的状态
1.synchronized用法
- 修饰一个代码块,被修饰的代码块称为同步语句块,其作用的范围是大括号{}括起来的代码,作用的对象是调用这个代码块的对象; 2. 修饰一个方法,被修饰的方法称为同步方法,其作用的范围是整个方法,作用的对象是调用这个方法的对象; 3. 修改一个静态的方法,其作用的范围是整个静态方法,作用的对象是这个类的所有对象; 4. 修改一个类,其作用的范围是synchronized后面括号括起来的部分,作用主的对象是这个类的所有对象。
2.Java中锁的四种状态
3.synchronized底层实现过程
4.synchronized和lock区别
- 来源:lock是一个接口,而synchronized是java的一个关键字,synchronized是内置的语言实现;
- 异常是否释放锁:synchronized在发生异常时候会自动释放占有的锁,因此不会出现死锁;而lock发生异常时候,不会主动释放占有的锁,必须手动unlock来释放锁,可能引起死锁的发生。(所以最好将同步代码块用try catch包起来,finally中写入unlock,避免死锁的发生。)
- 是否响应中断lock等待锁过程中可以用interrupt来中断等待,而synchronized只能等待锁的释放,不能响应中断;
- 是否知道获取锁Lock可以通过trylock来知道有没有获取锁,而synchronized不能;
- Lock可以提高多个线程进行读操作的效率。(可以通过readwritelock实现读写分离)
- 在性能上来说,如果竞争资源不激烈,两者的性能是差不多的,而当竞争资源非常激烈时(即有大量线程同时竞争),此时Lock的性能要远远优于synchronized。所以说,在具体使用时要根据适当情况选择。
synchronized使用Object对象本身的wait 、notify、notifyAll调度机制,而Lock可以使用Condition进行线程之间的调度,
1.CAS和ABA的问题
悲观锁
悲观锁,正如其名,具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度。因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。
当要对数据库中的一条数据进行修改的时候,为了避免同时被其他人修改,最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制,在修改数据之前先锁定,再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control,缩写“PCC”,又名“悲观锁”】。乐观锁
乐观锁是相对悲观锁而言的,乐观锁假设数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则返回给用户错误的信息,让用户决定如何去做。乐观锁适用于读操作多的场景,这样可以提高程序的吞吐量。
乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言,也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制,但乐观锁不会刻意使用数据库本身的锁机制,而是依据数据本身来保证数据的正确性。乐观锁的实现:CAS 实现:Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
- 版本号控制:一般是在数据表中加上一个数据版本号 version 字段,表示数据被修改的次数。当数据被修改时,version 值会+1。当线程A要更新数据值时,在读取数据的同时也会读取 version 值,在提交更新时,若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新,否则重试更新操作,直到更新成功。
乐观锁用到的机制就是CAS,Compare and Swap。
CAS有3个操作数,内存值V,旧的预期值A,要修改的新值B。当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做。
CAS看起来很爽,但是会导致“ABA问题”。
CAS算法实现一个重要前提需要取出内存中某时刻的数据,而在下时刻比较并替换,那么在这个时间差类会导致数据的变化。
比如说一个线程one从内存位置V中取出A,这时候另一个线程two也从内存中取出A,并且two进行了一些操作变成了B,然后two又将V位置的数据变成A,这时候线程one进行CAS操作发现内存中仍然是A,然后one操作成功。尽管线程one的CAS操作成功,但是不代表这个过程就是没有问题的。如果链表的头在变化了两次后恢复了原值,但是不代表链表就没有变化。因此前面提到的原子操作AtomicStampedReference/AtomicMarkableReference就很有用了。这允许一对变化的元素进行原子操作。
在运用CAS做Lock-Free操作中有一个经典的ABA问题:
线程1准备用CAS将变量的值由A替换为B,在此之前,线程2将变量的值由A替换为C,又由C替换为A,然后线程1执行CAS时发现变量的值仍然为A,所以CAS成功。但实际上这时的现场已经和最初不同了,尽管CAS成功,但可能存在潜藏的问题
2.Threadlocal的实现原理
ThreadLocal提供线程本地变量,每个线程拥有本地变量的副本,各个线程之间的变量互不干扰。ThreadLocal实现在多线程环境下去保证变量的安全。
3.什么是AQS
AQS:AbstractQueuedSynchronizer,即队列同步器。它是构建锁或者其他同步组件的基础框架(如ReentrantLock、ReentrantReadWriteLock、Semaphore等),JUC并发包的作者(Doug Lea)期望它能够成为实现大部分同步需求的基础。它是JUC并发包中的核心基础组件。
AQS解决了实现同步器时涉及当的大量细节问题,例如获取同步状态、FIFO同步队列。基于AQS来构建同步器可以带来很多好处。它不仅能够极大地减少实现工作,而且也不必处理在多个位置上发生的竞争问题。
在基于AQS构建的同步器中,只能在一个时刻发生阻塞,从而降低上下文切换的开销,提高了吞吐量。同时在设计AQS时充分考虑了可伸缩行,因此J.U.C中所有基于AQS构建的同步器均可以获得这个优势
AQS 内部简单来说其实主要是由三部分组成的
- state 这个状态用来声明对象是否已经被线程占有,状态为 0 表示没有,state > 0则表示已经被其他线程占有
- 当前线程 声明当前占有的线程
- 排队队列 等待占有该对象的线程
4.volitate的作用
volatile 的读性能消耗与普通变量几乎相同,但是写操作稍慢,因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。
内存可见性(Memory Visibility):所有线程都能看到共享内存的最新状态。5.线程池的五大状态
1.RUNNING
状态说明:线程池处在RUNNING状态时,能够接收新任务,以及对已添加的任务进行处理。状态切换:线程池的初始化状态是RUNNING。换句话说,线程池被一旦被创建,就处于RUNNING状态,并且线程池中的任务数为0!2.SHUTDOWN
状态说明:线程池处在SHUTDOWN状态时,不接收新任务,但能处理已添加的任务。状态切换:调用线程池的shutdown()接口时,线程池由RUNNING -> SHUTDOWN。3.STOP
状态说明:线程池处在STOP状态时,不接收新任务,不处理已添加的任务,并且会中断正在处理的任务。状态切换:调用线程池的shutdownNow()接口时,线程池由(RUNNING or SHUTDOWN ) -> STOP。4.TIDYING
状态说明:当所有的任务已终止,ctl记录的”任务数量”为0,线程池会变为TIDYING状态。当线程池变为TIDYING状态时,会执行钩子函数terminated()。terminated()在ThreadPoolExecutor类中是空的,若用户想在线程池变为TIDYING时,进行相应的处理;可以通过重载terminated()函数来实现。状态切换:当线程池在SHUTDOWN状态下,阻塞队列为空并且线程池中执行的任务也为空时,就会由 SHUTDOWN -> TIDYING。当线程池在STOP状态下,线程池中执行的任务为空时,就会由STOP -> TIDYING。5.TERMINATED
状态说明:线程池彻底终止,就变成TERMINATED状态。状态切换:线程池处在TIDYING状态时,执行完terminated()之后,就会由 TIDYING -> TERMINATED。
1.tcp的三次握手
2.tcp的四次挥手
TCP的三次握手与四次挥手理解及面试题(很全面)
序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。
终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。
三次握手过程理解
第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
四次挥手过程理解
1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。2)服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
常见面试题【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
3.lambda表达式
1. 什么是λ表达式
λ表达式本质上是一个匿名方法。让我们来看下面这个例子:
public int add(int x, int y) {<br /> return x + y;<br /> }
转成λ表达式后是这个样子:
(int x, int y) -> x + y;
参数类型也可以省略,Java编译器会根据上下文推断出来:
(x, y) -> x + y; //返回两数之和<br /> <br />或者
(x, y) -> { return x + y; } //显式指明返回值
可见λ表达式由三部分组成:参数列表,箭头(->),以及一个表达式或语句块。
下面这个例子里的λ表达式没有参数,也没有返回值(相当于一个方法接受0个参数,返回void,其实就是Runnable里run方法的一个实现):
() -> { System.out.println("Hello Lambda!"); }
如果只有一个参数且可以被Java推断出类型,那么参数列表的括号也可以省略:
list -> { return list.size(); }
2. λ表达式的类型(它是Object吗?)
λ表达式可以被当做是一个Object(注意措辞)。λ表达式的类型,叫做“目标类型(target type)”。λ表达式的目标类型是“函数式接口(functional interface)”,这是Java8新引入的概念。它的定义是:一个接口,如果只有一个显式声明的抽象方法,那么它就是一个函数式接口。一般用@FunctionalInterface标注出来(也可以不标)。举例如下:
@FunctionalInterface<br /> public interface Runnable { void run(); }<br /> <br /> public interface Callable<V> { V call() throws Exception; }<br /> <br /> public interface ActionListener { void actionPerformed(ActionEvent e); }<br /> <br /> public interface Comparator<T> { int compare(T o1, T o2); boolean equals(Object obj); }
注意最后这个Comparator接口。它里面声明了两个方法,貌似不符合函数式接口的定义,但它的确是函数式接口。这是因为equals方法是Object的,所有的接口都会声明Object的public方法——虽然大多是隐式的。所以,Comparator显式的声明了equals不影响它依然是个函式数接口。
你可以用一个λ表达式为一个函数式接口赋值:
Runnable r1 = () -> {System.out.println(“Hello Lambda!”);};
然后再赋值给一个Object:
Object obj = r1;<br /> <br />但却不能这样干:
Object obj = () -> {System.out.println("Hello Lambda!");}; // ERROR! Object is not a functional interface!
必须显式的转型成一个函数式接口才可以:
Object o = (Runnable) () -> { System.out.println("hi"); }; // correct<br /> <br />一个λ表达式只有在转型成一个函数式接口后才能被当做Object使用。所以下面这句也不能编译:
System.out.println( () -> {} ); //错误! 目标类型不明<br /> <br />必须先转型:
System.out.println( (Runnable)() -> {} ); // 正确
假设你自己写了一个函数式接口,长的跟Runnable一模一样:
@FunctionalInterface<br /> public interface MyRunnable {<br /> public void run();<br /> }<br /> <br />那么
Runnable r1 = () -> {System.out.println("Hello Lambda!");};<br /> MyRunnable2 r2 = () -> {System.out.println("Hello Lambda!");};
都是正确的写法。这说明一个λ表达式可以有多个目标类型(函数式接口),只要函数匹配成功即可。
但需注意一个λ表达式必须至少有一个目标类型。
JDK预定义了很多函数式接口以避免用户重复定义。最典型的是Function:
@FunctionalInterface<br /> public interface Function<T, R> { <br /> R apply(T t);<br /> }
这个接口代表一个函数,接受一个T类型的参数,并返回一个R类型的返回值。
另一个预定义函数式接口叫做Consumer,跟Function的唯一不同是它没有返回值。
@FunctionalInterface<br /> public interface Consumer<T> {<br /> void accept(T t);<br /> }
还有一个Predicate,用来判断某项条件是否满足。经常用来进行筛滤操作:
@FunctionalInterface
public interface Predicate
boolean test(T t);
}
综上所述,一个λ表达式其实就是定义了一个匿名方法,只不过这个方法必须符合至少一个函数式接口。
3. λ表达式的使用
3.1 λ表达式用在何处
λ表达式主要用于替换以前广泛使用的内部匿名类,各种回调,比如事件响应器、传入Thread类的Runnable等。看下面的例子:
Thread oldSchool = new Thread( new Runnable () {<br /> @Override<br /> public void run() {<br /> System.out.println("This is from an anonymous class.");<br /> }<br /> } );<br /> <br /> Thread gaoDuanDaQiShangDangCi = new Thread( () -> {<br /> System.out.println("This is from an anonymous method (lambda exp).");<br /> } );
注意第二个线程里的λ表达式,你并不需要显式地把它转成一个Runnable,因为Java能根据上下文自动推断出来:一个Thread的构造函数接受一个Runnable参数,而传入的λ表达式正好符合其run()函数,所以Java编译器推断它为Runnable。
从形式上看,λ表达式只是为你节省了几行代码。但将λ表达式引入Java的动机并不仅仅为此。Java8有一个短期目标和一个长期目标。短期目标是:配合“集合类批处理操作”的内部迭代和并行处理(下面将要讲到);长期目标是将Java向函数式编程语言这个方向引导(并不是要完全变成一门函数式编程语言,只是让它有更多的函数式编程语言的特性),也正是由于这个原因,Oracle并没有简单地使用内部类去实现λ表达式,而是使用了一种更动态、更灵活、易于将来扩展和改变的策略(invokedynamic)。
3.2 λ表达式与集合类批处理操作(或者叫块操作)
上文提到了集合类的批处理操作。这是Java8的另一个重要特性,它与λ表达式的配合使用乃是Java8的最主要特性。集合类的批处理操作API的目的是实现集合类的“内部迭代”,并期望充分利用现代多核CPU进行并行计算。
Java8之前集合类的迭代(Iteration)都是外部的,即客户代码。而内部迭代意味着改由Java类库来进行迭代,而不是客户代码。例如:
for(Object o: list) { // 外部迭代<br /> System.out.println(o);<br /> }
可以写成:
list.forEach(o -> {System.out.println(o);}); //forEach函数实现内部迭代
集合类(包括List)现在都有一个forEach方法,对元素进行迭代(遍历),所以我们不需要再写for循环了。forEach方法接受一个函数式接口Consumer做参数,所以可以使用λ表达式。
这种内部迭代方法广泛存在于各种语言,如C++的STL算法库、python、ruby、scala等。
Java8为集合类引入了另一个重要概念:流(stream)。一个流通常以一个集合类实例为其数据源,然后在其上定义各种操作。流的API设计使用了管道(pipelines)模式。对流的一次操作会返回另一个流。如同IO的API或者StringBuffer的append方法那样,从而多个不同的操作可以在一个语句里串起来。看下面的例子:
List<Shape> shapes = ...<br /> shapes.stream()<br /> .filter(s -> s.getColor() == BLUE)<br /> .forEach(s -> s.setColor(RED));
首先调用stream方法,以集合类对象shapes里面的元素为数据源,生成一个流。然后在这个流上调用filter方法,挑出蓝色的,返回另一个流。最后调用forEach方法将这些蓝色的物体喷成红色。(forEach方法不再返回流,而是一个终端方法,类似于StringBuffer在调用若干append之后的那个toString)
filter方法的参数是Predicate类型,forEach方法的参数是Consumer类型,它们都是函数式接口,所以可以使用λ表达式。
还有一个方法叫parallelStream(),顾名思义它和stream()一样,只不过指明要并行处理,以期充分利用现代CPU的多核特性。
shapes.parallelStream(); // 或shapes.stream().parallel()
来看更多的例子。下面是典型的大数据处理方法,Filter-Map-Reduce:
//给出一个String类型的数组,找出其中所有不重复的素数<br /> public void distinctPrimary(String... numbers) {<br /> List<String> l = Arrays.asList(numbers);<br /> List<Integer> r = l.stream()<br /> .map(e -> new Integer(e))<br /> .filter(e -> Primes.isPrime(e))<br /> .distinct()<br /> .collect(Collectors.toList());<br /> System.out.println("distinctPrimary result is: " + r);<br /> }
第一步:传入一系列String(假设都是合法的数字),转成一个List,然后调用stream()方法生成流。
第二步:调用流的map方法把每个元素由String转成Integer,得到一个新的流。map方法接受一个Function类型的参数,上面介绍了,Function是个函数式接口,所以这里用λ表达式。
第三步:调用流的filter方法,过滤那些不是素数的数字,并得到一个新流。filter方法接受一个Predicate类型的参数,上面介绍了,Predicate是个函数式接口,所以这里用λ表达式。
第四步:调用流的distinct方法,去掉重复,并得到一个新流。这本质上是另一个filter操作。
第五步:用collect方法将最终结果收集到一个List里面去。collect方法接受一个Collector类型的参数,这个参数指明如何收集最终结果。在这个例子中,结果简单地收集到一个List中。我们也可以用Collectors.toMap(e->e, e->e)把结果收集到一个Map中,它的意思是:把结果收到一个Map,用这些素数自身既作为键又作为值。toMap方法接受两个Function类型的参数,分别用以生成键和值,Function是个函数式接口,所以这里都用λ表达式。
你可能会觉得在这个例子里,List l被迭代了好多次,map,filter,distinct都分别是一次循环,效率会不好。实际并非如此。这些返回另一个Stream的方法都是“懒(lazy)”的,而最后返回最终结果的collect方法则是“急(eager)”的。在遇到eager方法之前,lazy的方法不会执行。
当遇到eager方法时,前面的lazy方法才会被依次执行。而且是管道贯通式执行。这意味着每一个元素依次通过这些管道。例如有个元素“3”,首先它被map成整数型3;然后通过filter,发现是素数,被保留下来;又通过distinct,如果已经有一个3了,那么就直接丢弃,如果还没有则保留。这样,3个操作其实只经过了一次循环。
除collect外其它的eager操作还有forEach,toArray,reduce等。
下面来看一下也许是最常用的收集器方法,groupingBy:
//给出一个String类型的数组,找出其中各个素数,并统计其出现次数<br /> public void primaryOccurrence(String... numbers) {<br /> List<String> l = Arrays.asList(numbers);<br /> Map<Integer, Integer> r = l.stream()<br /> .map(e -> new Integer(e))<br /> .filter(e -> Primes.isPrime(e))<br /> .collect( Collectors.groupingBy(p->p, Collectors.summingInt(p->1)) );<br /> System.out.println("primaryOccurrence result is: " + r);<br /> }
注意这一行:
Collectors.groupingBy(p->p, Collectors.summingInt(p->1))
它的意思是:把结果收集到一个Map中,用统计到的各个素数自身作为键,其出现次数作为值。
下面是一个reduce的例子:
//给出一个String类型的数组,求其中所有不重复素数的和<br /> public void distinctPrimarySum(String... numbers) {<br /> List<String> l = Arrays.asList(numbers);<br /> int sum = l.stream()<br /> .map(e -> new Integer(e))<br /> .filter(e -> Primes.isPrime(e))<br /> .distinct()<br /> .reduce(0, (x,y) -> x+y); // equivalent to .sum()<br /> System.out.println("distinctPrimarySum result is: " + sum);<br /> }
reduce方法用来产生单一的一个最终结果。
流有很多预定义的reduce操作,如sum(),max(),min()等。
再举个现实世界里的栗子比如:
// 统计年龄在25-35岁的男女人数、比例<br /> public void boysAndGirls(List<Person> persons) {<br /> Map<Integer, Integer> result = persons.parallelStream().filter(p -> p.getAge()>=25 && p.getAge()<=35).<br /> collect(<br /> Collectors.groupingBy(p->p.getSex(), Collectors.summingInt(p->1))<br /> );<br /> System.out.print("boysAndGirls result is " + result);<br /> System.out.println(", ratio (male : female) is " + (float)result.get(Person.MALE)/result.get(Person.FEMALE));<br /> }
4.反射的理解
5.自定义注解的作用
注解就是某种注解类型的一个实例,我们可以用它在某个类上进行标注,这样编译器在编译我们的文件时,会根据我们自己设定的方法来编译类。
1.Cookie和Session的区别
2.Mysql的存储引擎的区别
3.on having where的区别
4.索引的数据结构B+Tree
5.索引的分类,聚簇索引,覆盖索引,联合索引,最左匹配
索引概念、索引模型对于查询做一些优化?
A:我们在数据库中创建了一些索引
Q:那你能说说什么是索引吗?
A:(这道题肯定难不住我啊)索引其实是一种数据结构,能够帮助我们快速的检索数据库中的数据
Q:那么索引具体采用的哪种数据结构呢?
A:常见的MySQL主要有两种结构:Hash索引和B+ Tree索引,我们使用的是InnoDB引擎,默认的是B+树
Q:既然你提到InnoDB使用的B+ 树的索引模型,那么你知道为什么采用B+ 树吗?这和Hash索引比较起来有什么优缺点吗?
A:(突然觉得这道题有点难,但是我还是凭借着自己的知识储备简单的回答上一些)因为Hash索引底层是哈希表,哈希表是一种以key-value存储数据的结构,所以多个数据在存储关系上是完全没有任何顺序关系的,所以,对于区间查询是无法直接通过索引查询的,就需要全表扫描。所以,哈希索引只适用于等值查询的场景。而B+ 树是一种多路平衡查询树,所以他的节点是天然有序的(左子节点小于父节点、父节点小于右子节点),所以对于范围查询的时候不需要做全表扫描
Q:除了上面这个范围查询的,你还能说出其他的一些区别吗?
A:(这个题我回答的不好,事后百度了一下)
B+Tree索引和Hash索引区别?
哈希索引适合等值查询,但是无法进行范围查询
哈希索引没办法利用索引完成排序
哈希索引不支持多列联合索引的最左匹配规则
如果有大量重复键值的情况下,哈希索引的效率会很低,因为存在哈希碰撞问题
聚簇索引、覆盖索引
Q:刚刚我们聊到B+ Tree ,那你知道B+ Tree的叶子节点都可以存哪些东西吗?
A:InnoDB的B+ Tree可能存储的是整行数据,也有可能是主键的值
Q:那这两者有什么区别吗?
A:(当他问我叶子节点的时候,其实我就猜到他可能要问我聚簇索引和非聚簇索引了)在 InnoDB 里,索引B+ Tree的叶子节点存储了整行数据的是主键索引,也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引,也被称之为非聚簇索引
Q:那么,聚簇索引和非聚簇索引,在查询数据的时候有区别吗?
A:聚簇索引查询会更快?
Q:为什么呢?
A:因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点是主键的值,查到主键的值以后,还需要再通过主键的值再进行一次查询
Q:刚刚你提到主键索引查询只会查一次,而非主键索引需要回表查询多次。(后来我才知道,原来这个过程叫做回表)是所有情况都是这样的吗?非主键索引一定会查询多次吗?
A:(额、这个问题我回答的不好,后来我自己查资料才知道,通过覆盖索引也可以只查询一次)
覆盖索引?
覆盖索引(covering index)指一个查询语句的执行只用从索引中就能够取得,不必从数据表中读取。也可以称之为实现了索引覆盖。
当一条查询语句符合覆盖索引条件时,MySQL只需要通过索引就可以返回查询所需要的数据,这样避免了查到索引后再返回表操作,减少I/O提高效率。
如,表covering_index_sample中有一个普通索引 idx_key1_key2(key1,key2)。
当我们通过SQL语句:select key2 from covering_index_sample where key1 = ‘keytest’;的时候,就可以通过覆盖索引查询,无需回表。
联合索引、最左前缀匹配
Q:不知道的话没关系,想问一下,你们在创建索引的时候都会考虑哪些因素呢?
A:我们一般对于查询概率比较高,经常作为where条件的字段设置索引
Q: 那你们有用过联合索引吗?
A:用过呀,我们有对一些表中创建过联合索引
Q:那你们在创建联合索引的时候,需要做联合索引多个字段之间顺序你们是如何选择的呢?
A:我们把识别度最高的字段放到最前面
Q:为什么这么做呢?
A:(这个问题有点把我问蒙了,稍微有些慌乱)这样的话可能命中率会高一点吧。。。
Q: 那你知道最左前缀匹配吗?
A:(我突然想起来原来面试官是想问这个,怪自己刚刚为什么就没想到这个呢。)哦哦哦。您刚刚问的是这个意思啊,在创建多列索引时,我们根据业务需求,where子句中使用最频繁的一列放在最左边,因为MySQL索引查询会遵循最左前缀匹配的原则,即最左优先,在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候,如(key1,key2,key3),相当于创建了(key1)、(key1,key2)和(key1,key2,key3)三个索引,这就是最左匹配原则
索引下推、查询优化
你们线上用的MySQL是哪个版本啊呢?
A:我们MySQL是5.7
Q:那你知道在MySQL 5.6中,对索引做了哪些优化吗?
A:不好意思,这个我没有去了解过。(事后我查了一下,有一个比较重要的 :Index Condition Pushdown Optimization)
Index Condition Pushdown(索引下推)
MySQL 5.6引入了索引下推优化,默认开启,使用SET optimizer_switch = ‘index_condition_pushdown=off’;可以将其关闭。官方文档中给的例子和解释如下:
people表中(zipcode,lastname,firstname)构成一个索引
SELECT * FROM people WHERE zipcode=‘95054’ AND lastname LIKE ‘%etrunia%’ AND address LIKE ‘%Main Street%’;
如果没有使用索引下推技术,则MySQL会通过zipcode=’95054’从存储引擎中查询对应的数据,返回到MySQL服务端,然后MySQL服务端基于lastname LIKE ‘%etrunia%’和address LIKE ‘%Main Street%’来判断数据是否符合条件。
如果使用了索引下推技术,则MYSQL首先会返回符合zipcode=’95054’的索引,然后根据lastname LIKE ‘%etrunia%’和address LIKE ‘%Main Street%’来判断索引是否符合条件。如果符合条件,则根据该索引来定位对应的数据,如果不符合,则直接reject掉。有了索引下推优化,可以在有like条件查询的情况下,减少回表次数。
Q:你们创建的那么多索引,到底有没有生效,或者说你们的SQL语句有没有使用索引查询你们有统计过吗?
A:这个还没有统计过,除非遇到慢SQL的时候我们才会去排查
Q:那排查的时候,有什么手段可以知道有没有走索引查询呢?
A:可以通过explain查看sql语句的执行计划,通过执行计划来分析索引使用情况
Q:那什么情况下会发生明明创建了索引,但是执行的时候并没有通过索引呢?
A:(大概记得和优化器有关,但是这个问题并没有回答好)
查询优化器
?
一条SQL语句的查询,可以有不同的执行方案,至于最终选择哪种方案,需要通过优化器进行选择,选择执行成本最低的方案。
在一条单表查询语句真正执行之前,MySQL的查询优化器会找出执行该语句所有可能使用的方案,对比之后找出成本最低的方案。
这个成本最低的方案就是所谓的执行计划。优化过程大致如下:
1、根据搜索条件,找出所有可能使用的索引
2、计算全表扫描的代价
3、计算使用不同索引执行查询的代价
4、对比各种执行方案的代价,找出成本最低的那一个
1.servlet生命周期
1.servlet的生命周期
主要有三个方法:
init()初始化阶段
service()处理客户端请求阶段
destroy()终止阶段
初始化阶段:
Servlet容器加载Servlet,加载完成后,Servlet容器会创建一个Servlet实例并调用init()方法,init()方法只会调用一次
Servlet容器会在一下几种情况装载Servlet:
Servlet容器启动时自动装载某些servlet,实现这个需要在web.xml文件中添加1
在Servlet容器启动后,客户首次向Servlet发送请求
Servlet类文件被更新后,重新装载
处理客户端请求阶段:
每收到一个客户端请求,服务器就会产生一个新的线程去处理。
对于用户的Servlet请求,Servlet容器会创建一个特定于请求的ServletRequest和ServletResponse。
对于tomcat来说,它会将传递来的参数放入一个HashTable中,这是一个String–>String[]的键值映射
终止阶段:
当web应用被终止,或者Servlet容器终止运行,或者Servlet重新装载Servlet新实例时,Servlet容器会调用Servlet的destroy()方法
2.servlet的工作原理
客户发送一个请求,Servlet调用service()方法对请求进行响应,service()方法会对请求的方法进行匹配,进入相应的逻辑层,完成请求的响应。
但是Servlet接口和GenericServlet接口中没有doGet(),doPost()等方法,HttpServlet中定义了这些,但是返回的都是Error信息,所以每次定义Servlet都要重写这些方法。
Sertvlet和GenericServlet是不特定于任何协议的,而HttpServlet是特定于Http协议的,所以HttpServlet中的service()方法中将ServletRequest,ServletResponse强转为HttpRequest和HttpResponse,最后调用自己的service方法去完成响应。
2.事务的理解
什么是事务?
事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时,所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改,在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时,数据的状态都应该正确。
通俗的理解,事务是一组原子操作单元,从数据库角度说,就是一组SQL指令,要么全部执行成功,若因为某个原因其中一条指令执行有错误,则撤销先前执行过的所有指令。更简答的说就是:要么全部执行成功,要么撤销不执行。
事务在并发情况下带来的问题
1、脏读(针对未提交数据):事务A对某一条数据进行了操作,但是并未提交,此时事务B读取到了事务A还未提交的操作后的该条数据,如果事务A发生回滚,事务B读到的数据就是错误的,这种现象被称为脏读
具体例子:灰太狼查看自己家里银行卡里的存款(卡里拥有5000元),灰太狼查看存款(事务A开启),同时红太狼进行取款(事务B开启),取走1000元(事务B并未提交),此时灰太狼查看到的存款为4000元(查看到了红太狼取完款后的银行卡余额,事务A结束),但是红太狼又将1000元存回去(事务B结束),实际上此时卡里还有5000元,但是灰太狼误以为只有4000元,这就是一种典型的脏读现象。
2、不可重复读(针对其他事物提交前后,读取数据本身的对比):事务A读取到了某一条数据,然后事务A执行他的逻辑,此时事务B修改了该条数据,事务A再次读取到该条数据时,发现和第一次读取到的数据不一致,这种现象被称为不可重复读
具体例子:灰太狼查看自己家里银行卡里的存款(卡里拥有5000元),灰太狼查看存款(事务A开启),查看到存款为5000元,同时红太狼进行取款(事务B开启),取走1000元(事务B结束),然后灰太狼再次查看存款为4000元(事务A结束),在同一个事务内两次读到的银行卡余额不同,这就是一种典型的不可重复读现象。
3、幻读(针对其他事物提交前后,读取数据条数的对比):事务A读取到了符合一个条件的某几条(N条)数据,事务B增添了符合该条件的(M条)几条数据,并提交,事务A再次读取符合该条件的数据时,读到的条数为(N+M条)与第一次读取到的条数不相等,这种现象被称为幻读
具体例子:灰太狼抓到了几只羊,出门买调料前,数了一遍锅里的羊(事务A开启),有3只,就出门了。灰太狼出门后红太狼又从羊村抓了2只羊回来放到锅里(事务B),灰太狼回家后数了一下锅里的羊,有5只羊,灰太狼还以为自己第一次数错了,这便是一种典型的幻读现象。
3.事务隔离级别
事务的隔离级别拥有四种:
1、Read Uncommitted(读未提交):事务修改数据后即使未提交,其他事务也可以读取到该事务修改后未被提交的数据,所以这个级别的隔离机制无法解决脏读、不可重复读、幻读中的任何一种
2、Read Committed (读已提交):能够读取到那些已经提交的数据,能够防止脏读,但是无法解决不可重复读和幻读的问题
3、Repeatable Read(重复读):在数据读取出来后对其加锁,防止别人修改他,即读取了一条数据,改事务不结束,别的事务就不能修改这条记录,能够解决脏读、不可重复读的问题,但是幻读依旧解决不了
4、Serializable(串行化):最高级别的事务隔离级别,不管拥有多少事务,只有执行完一个完整的事务后才能执行下一个事务,这样能够避免脏读、不可重复读、幻读的问题
事务的隔离级别设置的越高,事务对数据进行操作的行为就越安全,但是安全的代价是事务执行效率的降低,所以事务的隔离级别并不是设置的越高越好,实际开发中我们需要在安全性和执行效率之间做一个权重比
查看事务的隔离级别以及修改的命令
查看mysql事务隔离级别命令
查看会话当前隔离级别:SELECT @@TX_ISOLATION;
查看系统当前隔离级别:SELECT @@GLOBAL.TX_ISOLATION;
修改会话当前的隔离级别:SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; (READ UNCOMMITTED || READ COMMITTED || REAPEATABLE READ)
修改系统当前的隔离级别:SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;(READ UNCOMMITTED || READ COMMITTED || REAPEATABLE READ)
4.Spring的事务传播行为
- Transaction 英/trænˈzækʃn/
什么叫事务传播行为?听起来挺高端的,其实很简单。 即然是传播,那么至少有两个东西,才可以发生传播。单体不存在传播这个行为。
事务传播行为(propagation behavior)指的就是当一个事务方法被另一个事务方法调用时,这个事务方法应该如何进行。 例如:methodA事务方法调用methodB事务方法时,methodB是继续在调用者methodA的事务中运行呢,还是为自己开启一个新事务运行,这就是由methodB的事务传播行为决定的。
pring中七种事务传播行为
事务的传播行为,默认值为 Propagation.REQUIRED。可以手动指定其他的事务传播行为,如下:
- Propagation.REQUIRED
如果当前存在事务,则加入该事务,如果当前不存在事务,则创建一个新的事务。
- Propagation.SUPPORTS
如果当前存在事务,则加入该事务;如果当前不存在事务,则以非事务的方式继续运行。
- Propagation.MANDATORY 美/ˈmændətɔːri/强制的 强制性 命令的 义务的
如果当前存在事务,则加入该事务;如果当前不存在事务,则抛出异常。
- Propagation.REQUIRES_NEW
重新创建一个新的事务,如果当前存在事务,延缓当前的事务。
- Propagation.NOT_SUPPORTED
以非事务的方式运行,如果当前存在事务,暂停当前的事务。
- Propagation.NEVER
以非事务的方式运行,如果当前存在事务,则抛出异常。
- Propagation.NESTED 美/ˈnestɪd/ 嵌套 巢状
如果没有,就新建一个事务;如果有,就在当前事务中嵌套其他事务。
1.spring循环依赖产生和解决
Spring 的三种循环依赖
- 构造器的循环依赖,处理不了,直接抛出 BeanCurrentlylnCreationException 异常;
- 非单例的循环依赖,处理不了;
- 单例模式的 setter 或 @Autowired 循环依赖,通过三级缓存来处理。
一级、二级、三级缓存介绍
singletonObjects,一级缓存。 用于存放已实例化和初始化完成(属性赋值)的 Bean,即我们常用到 Bean;
earlySingletonObjects,二级缓存。 存放已实例化但未初始化的 Bean 引用;
singletonFactories,三级缓存。 存放已实例化,但未初始化的 Bean 工厂。
二级缓存和三级缓存的区别在于,二级缓存的 Bean 会增加一些扩展功能。比如二级缓存的 Bean 引用为动态代理, 先从三级缓存中获取 Bean,然后为其创建代理对象,之后放到二级缓存中,这也是为什么需要二级缓存的原因。
以 B 对象,A 属性为例,使用三级缓存 B 对象获取到的是半成品 A 对象(属性)的原始引用。如果在最后创建完成,放入一级缓存中的完成品 A 是代理引用,这与期望要求的不同,所以会多一个二级缓存,用于存放三级缓存的 Bean 的代理引用。
三级缓存的解决思路
还是以上面的 A 依赖 B,B 依赖 A 为例。
Spring 发现 A 对象,实例化 A,但没有放到 Spring 对象池(一级缓存中),将半成品 A 放到三级缓存中;
A 对象还需要完成初始化,注入属性 B,于是从 Spring 对象池中获取 B 实例;
但没获取到,于是 Spring 会进入到 B 属性,同样是实例化 B,但没放到 Spring 对象池中,将半成品 B 放到三级缓存中;
接着 B 对象获取属性 A(对象),从三级缓存中获取到半成品 A,进行属性注入,至此 B 对象完成实例化和属性初始化,会放到一级缓存中,并返回;
A 对象获取到 B 对象,进行属性注入,于是 A 对象也完成实例化和初始化会放到一级缓存中。
在 B 进行属性注入,获取 A 对象时,会从三级缓存中先获取一个半成品 A,只有实例化,还没完成属性初始化的 A。这就打破了循环,解决循环依赖。
2.谈谈对ioc和di的理解
2.1、IoC(控制反转)
首先想说说IoC(Inversion of Control,控制反转)。这是spring的核心,贯穿始终。所谓IoC,对于spring框架来说,就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢,举个简单的例子,我们是如何找女朋友的?常见的情况是,我们到处去看哪里有长得漂亮身材又好的mm,然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………,想办法认识她们,投其所好送其所要,然后嘿嘿……这个过程是复杂深奥的,我们必须自己设计和面对每个环节。传统的程序开发也是如此,在一个对象中,如果要使用另外的对象,就必须得到它(自己new一个,或者从JNDI中查询一个),使用完之后还要将对象销毁(比如Connection等),对象始终会和其他的接口或类藕合起来。
那么IoC是如何做的呢?有点像通过婚介找女朋友,在我和女朋友之间引入了一个第三者:婚姻介绍所。婚介管理了很多男男女女的资料,我可以向婚介提出一个列表,告诉它我想找个什么样的女朋友,比如长得像李嘉欣,身材像林熙雷,唱歌像周杰伦,速度像卡洛斯,技术像齐达内之类的,然后婚介就会按照我们的要求,提供一个mm,我们只需要去和她谈恋爱、结婚就行了。简单明了,如果婚介给我们的人选不符合要求,我们就会抛出异常。整个过程不再由我自己控制,而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此,所有的类都会在spring容器中登记,告诉spring你是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制,也就是说控制对象生存周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象都被spring控制,所以这叫控制反转。
2.2、DI(依赖注入)
IoC的一个重点是在系统运行中,动态的向某个对象提供它所需要的其他对象。这一点是通过DI(Dependency Injection,依赖注入)来实现的。比如对象A需要操作数据库,以前我们总是要在A中自己编写代码来获得一个Connection对象,有了 spring我们就只需要告诉spring,A中需要一个Connection,至于这个Connection怎么构造,何时构造,A不需要知道。在系统运行时,spring会在适当的时候制造一个Connection,然后像打针一样,注射到A当中,这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行,而这个Connection是由spring注入到A中的,依赖注入的名字就这么来的。那么DI是如何实现的呢? Java 1.3之后一个重要特征是反射(reflection),它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性,spring就是通过反射来实现注入的。
3.请说出spring bean的生命周期
1.SpringBoot的自动装配原理
2.SpringMVC的运行流程
SpringMVC的工作原理图:
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响应用户。
组件说明:
以下组件通常使用框架提供实现:
DispatcherServlet:作为前端控制器,整个流程控制的中心,控制其它组件执行,统一调度,降低组件之间的耦合性,提高每个组件的扩展性。
HandlerMapping:通过扩展处理器映射器实现不同的映射方式,例如:配置文件方式,实现接口方式,注解方式等。
HandlAdapter:通过扩展处理器适配器,支持更多类型的处理器。
ViewResolver:通过扩展视图解析器,支持更多类型的视图解析,例如:jsp、freemarker、pdf、excel等。
组件:
1、前端控制器DispatcherServlet(不需要工程师开发),由框架提供
作用:接收请求,响应结果,相当于转发器,中央处理器。有了dispatcherServlet减少了其它组件之间的耦合度。
用户请求到达前端控制器,它就相当于mvc模式中的c,dispatcherServlet是整个流程控制的中心,由它调用其它组件处理用户的请求,dispatcherServlet的存在降低了组件之间的耦合性。
2、处理器映射器HandlerMapping(不需要工程师开发),由框架提供
作用:根据请求的url查找Handler
HandlerMapping负责根据用户请求找到Handler即处理器,springmvc提供了不同的映射器实现不同的映射方式,例如:配置文件方式,实现接口方式,注解方式等。
3、处理器适配器HandlerAdapter
作用:按照特定规则(HandlerAdapter要求的规则)去执行Handler
通过HandlerAdapter对处理器进行执行,这是适配器模式的应用,通过扩展适配器可以对更多类型的处理器进行执行。
4、处理器Handler(需要工程师开发)
注意:编写Handler时按照HandlerAdapter的要求去做,这样适配器才可以去正确执行Handler
Handler 是继DispatcherServlet前端控制器的后端控制器,在DispatcherServlet的控制下Handler对具体的用户请求进行处理。
由于Handler涉及到具体的用户业务请求,所以一般情况需要工程师根据业务需求开发Handler。
5、视图解析器View resolver(不需要工程师开发),由框架提供
作用:进行视图解析,根据逻辑视图名解析成真正的视图(view)
View Resolver负责将处理结果生成View视图,View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址,再生成View视图对象,最后对View进行渲染将处理结果通过页面展示给用户。 springmvc框架提供了很多的View视图类型,包括:jstlView、freemarkerView、pdfView等。
一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户,需要由工程师根据业务需求开发具体的页面。
6、视图View(需要工程师开发jsp…)
View是一个接口,实现类支持不同的View类型(jsp、freemarker、pdf…)
核心架构的具体流程步骤如下:
1、首先用户发送请求——>DispatcherServlet,前端控制器收到请求后自己不进行处理,而是委托给其他的解析器进行处理,作为统一访问点,进行全局的流程控制;
2、DispatcherServlet——>HandlerMapping, HandlerMapping 将会把请求映射为HandlerExecutionChain 对象(包含一个Handler 处理器(页面控制器)对象、多个HandlerInterceptor 拦截器)对象,通过这种策略模式,很容易添加新的映射策略;
3、DispatcherServlet——>HandlerAdapter,HandlerAdapter 将会把处理器包装为适配器,从而支持多种类型的处理器,即适配器设计模式的应用,从而很容易支持很多类型的处理器;
4、HandlerAdapter——>处理器功能处理方法的调用,HandlerAdapter 将会根据适配的结果调用真正的处理器的功能处理方法,完成功能处理;并返回一个ModelAndView 对象(包含模型数据、逻辑视图名);
5、ModelAndView的逻辑视图名——> ViewResolver, ViewResolver 将把逻辑视图名解析为具体的View,通过这种策略模式,很容易更换其他视图技术;
6、View——>渲染,View会根据传进来的Model模型数据进行渲染,此处的Model实际是一个Map数据结构,因此很容易支持其他视图技术;
7、返回控制权给DispatcherServlet,由DispatcherServlet返回响应给用户,到此一个流程结束。
下边两个组件通常情况下需要开发:
Handler:处理器,即后端控制器用controller表示。
View:视图,即展示给用户的界面,视图中通常需要标签语言展示模型数据。
在将SpringMVC之前我们先来看一下什么是MVC模式
MVC:MVC是一种设计模式
MVC的原理图:
分析:
M-Model 模型(完成业务逻辑:有javaBean构成,service+dao+entity)
V-View 视图(做界面的展示 jsp,html……)
C-Controller 控制器(接收请求—>调用模型—>根据结果派发页面)
springMVC是什么:
springMVC是一个MVC的开源框架,springMVC=struts2+spring,springMVC就相当于是Struts2加上sring的整合,但是这里有一个疑惑就是,springMVC和spring是什么样的关系呢?这个在百度百科上有一个很好的解释:意思是说,springMVC是spring的一个后续产品,其实就是spring在原有基础上,又提供了web应用的MVC模块,可以简单的把springMVC理解为是spring的一个模块(类似AOP,IOC这样的模块),网络上经常会说springMVC和spring无缝集成,其实springMVC就是spring的一个子模块,所以根本不需要同spring进行整合。
SpringMVC的原理图:
看到这个图大家可能会有很多的疑惑,现在我们来看一下这个图的步骤:(可以对比MVC的原理图进行理解)
第一步:用户发起请求到前端控制器(DispatcherServlet)
第二步:前端控制器请求处理器映射器(HandlerMappering)去查找处理器(Handle):通过xml配置或者注解进行查找
第三步:找到以后处理器映射器(HandlerMappering)像前端控制器返回执行链(HandlerExecutionChain)
第四步:前端控制器(DispatcherServlet)调用处理器适配器(HandlerAdapter)去执行处理器(Handler)
第五步:处理器适配器去执行Handler
第六步:Handler执行完给处理器适配器返回ModelAndView
第七步:处理器适配器向前端控制器返回ModelAndView
第八步:前端控制器请求视图解析器(ViewResolver)去进行视图解析
第九步:视图解析器像前端控制器返回View
第十步:前端控制器对视图进行渲染
第十一步:前端控制器向用户响应结果
看到这些步骤我相信大家很感觉非常的乱,这是正常的,但是这里主要是要大家理解springMVC中的几个组件:
前端控制器(DispatcherServlet):接收请求,响应结果,相当于电脑的CPU。
处理器映射器(HandlerMapping):根据URL去查找处理器
处理器(Handler):(需要程序员去写代码处理逻辑的)
处理器适配器(HandlerAdapter):会把处理器包装成适配器,这样就可以支持多种类型的处理器,类比笔记本的适配器(适配器模式的应用)
视图解析器(ViewResovler):进行视图解析,多返回的字符串,进行处理,可以解析成对应的页面
3.SpringMVC的常用注解和意义
1、@Controller
在SpringMVC 中,控制器Controller 负责处理由DispatcherServlet 分发的请求,它把用户请求的数据经过业务处理层处理之后封装成一个Model ,然后再把该Model 返回给对应的View 进行展示。在SpringMVC 中提供了一个非常简便的定义Controller 的方法,你无需继承特定的类或实现特定的接口,只需使用@Controller 标记一个类是Controller ,然后使用@RequestMapping 和@RequestParam 等一些注解用以定义URL 请求和Controller 方法之间的映射,这样的Controller 就能被外界访问到。此外Controller 不会直接依赖于HttpServletRequest 和HttpServletResponse 等HttpServlet 对象,它们可以通过Controller 的方法参数灵活的获取到。
@Controller 用于标记在一个类上,使用它标记的类就是一个SpringMVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法,并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类,而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是SpringMVC 的一个控制器类,因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢?这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式:
(1)在SpringMVC 的配置文件中定义MyController 的bean 对象。
(2)在SpringMVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。
2、@RequestMapping
RequestMapping是一个用来处理请求地址映射的注解,可用于类或方法上。用于类上,表示类中的所有响应请求的方法都是以该地址作为父路径。
RequestMapping注解有六个属性,下面我们把她分成三类进行说明(下面有相应示例)。
1、 value, method;
value: 指定请求的实际地址,指定的地址可以是URI Template 模式(后面将会说明);
method: 指定请求的method类型, GET、POST、PUT、DELETE等;
2、consumes,produces
consumes: 指定处理请求的提交内容类型(Content-Type),例如application/json, text/html;
produces: 指定返回的内容类型,仅当request请求头中的(Accept)类型中包含该指定类型才返回;
3、params,headers
params: 指定request中必须包含某些参数值是,才让该方法处理。
headers: 指定request中必须包含某些指定的header值,才能让该方法处理请求。
3、@Resource和@Autowired
@Resource和@Autowired都是做bean的注入时使用,其实@Resource并不是Spring的注解,它的包是javax.annotation.Resource,需要导入,但是Spring支持该注解的注入。
1、共同点
两者都可以写在字段和setter方法上。两者如果都写在字段上,那么就不需要再写setter方法。
2、不同点
(1)@Autowired
@Autowired为Spring提供的注解,需要导入包org.springframework.beans.factory.annotation.Autowired;只按照byType注入。
public class TestServiceImpl { // 下面两种@Autowired只要使用一种即可 @Autowired private UserDao userDao; // 用于字段上 @Autowired public void setUserDao(UserDao userDao) { // 用于属性的方法上 this.userDao = userDao; } }
@Autowired注解是按照类型(byType)装配依赖对象,默认情况下它要求依赖对象必须存在,如果允许null值,可以设置它的required属性为false。如果我们想使用按照名称(byName)来装配,可以结合@Qualifier注解一起使用。如下:
public class TestServiceImpl { @Autowired @Qualifier(“userDao”) private UserDao userDao; }
(2)@Resource
@Resource默认按照ByName自动注入,由J2EE提供,需要导入包javax.annotation.Resource。@Resource有两个重要的属性:name和type,而Spring将@Resource注解的name属性解析为bean的名字,而type属性则解析为bean的类型。所以,如果使用name属性,则使用byName的自动注入策略,而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性,这时将通过反射机制使用byName自动注入策略。
public class TestServiceImpl {
// 下面两种@Resource只要使用一种即可
@Resource(name="userDao")
private UserDao userDao;
// 用于字段上
@Resource(name="userDao")
public void setUserDao(UserDao userDao) {
// 用于属性的setter方法上
this.userDao = userDao;
} }
注:最好是将@Resource放在setter方法上,因为这样更符合面向对象的思想,通过set、get去操作属性,而不是直接去操作属性。
@Resource装配顺序:
①如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常。
②如果指定了name,则从上下文中查找名称(id)匹配的bean进行装配,找不到则抛出异常。
③如果指定了type,则从上下文中找到类似匹配的唯一bean进行装配,找不到或是找到多个,都会抛出异常。
④如果既没有指定name,又没有指定type,则自动按照byName方式进行装配;如果没有匹配,则回退为一个原始类型进行匹配,如果匹配则自动装配。
@Resource的作用相当于@Autowired,只不过@Autowired按照byType自动注入。
4、@ModelAttribute和 @SessionAttributes
代表的是:该Controller的所有方法在调用前,先执行此@ModelAttribute方法,可用于注解和方法参数中,可以把这个@ModelAttribute特性,应用在BaseController当中,所有的Controller继承BaseController,即可实现在调用Controller时,先执行@ModelAttribute方法。
@SessionAttributes即将值放到session作用域中,写在class上面。
具体示例参见下面:使用 @ModelAttribute 和 @SessionAttributes 传递和保存数据
5、@PathVariable
用于将请求URL中的模板变量映射到功能处理方法的参数上,即取出uri模板中的变量作为参数。如:
@Controller
public class TestController {
@RequestMapping(value="/user/{userId}/roles/{roleId}",method = RequestMethod.GET)
public String getLogin(@PathVariable("userId") String userId,
@PathVariable("roleId") String roleId){
System.out.println("User Id : " + userId);
System.out.println("Role Id : " + roleId);
return "hello";
}
@RequestMapping(value="/product/{productId}",method = RequestMethod.GET)
public String getProduct(@PathVariable("productId") String productId){
System.out.println("Product Id : " + productId);
return "hello";
}
@RequestMapping(value="/javabeat/{regexp1:[a-z-]+}",
method = RequestMethod.GET)
public String getRegExp(@PathVariable("regexp1") String regexp1){
System.out.println("URI Part 1 : " + regexp1);
return "hello";
}
}
6、@requestParam
@requestParam主要用于在SpringMVC后台控制层获取参数,类似一种是request.getParameter(“name”),它有三个常用参数:defaultValue = “0”, required = false, value = “isApp”;defaultValue 表示设置默认值,required 铜过boolean设置是否是必须要传入的参数,value 值表示接受的传入的参数类型。
7、@ResponseBody
作用: 该注解用于将Controller的方法返回的对象,通过适当的HttpMessageConverter转换为指定格式后,写入到Response对象的body数据区。
使用时机:返回的数据不是html标签的页面,而是其他某种格式的数据时(如json、xml等)使用;
8、@Component
相当于通用的注解,当不知道一些类归到哪个层时使用,但是不建议。
9、@Repository
4.Mybatis的原理
mybatis应用程序通过SqlSessionFactoryBuilder从mybatis-config.xml配置文件(也可以用Java文件配置的方式,需要添加@Configuration)来构建SqlSessionFactory(SqlSessionFactory是线程安全的);
然后,SqlSessionFactory的实例直接开启一个SqlSession,再通过SqlSession实例获得Mapper对象并运行Mapper映射的SQL语句,完成对数据库的CRUD和事务提交,之后关闭SqlSession。
说明:SqlSession是单线程对象,因为它是非线程安全的,是持久化操作的独享对象,类似jdbc中的Connection,底层就封装了jdbc连接。
详细流程如下:
1、加载mybatis全局配置文件(数据源、mapper映射文件等),解析配置文件,MyBatis基于XML配置文件生成Configuration,和一个个MappedStatement(包括了参数映射配置、动态SQL语句、结果映射配置),其对应着