疏漏总结(四)

yield和join

Thread.yield()作用是暂停当前的正在执行的线程去执行其他的线程。

yield()做的是让当前运行线程回到可运行状态，允许相同优先级的线程后的运行的机会。使用其的目的是使相同优先级的线程之间能够适当的轮转执行。但是实际情况是yield并不能保证达到让步因为让步的线程还有可能被线程调度再次选中。

总的来说就是yield不会让线程转到等待/睡眠/阻塞状态，很多情况下yield将线程从运行状态转到可运行的状态。

join()方法作用是线程实例的join()方法可以让一个线程在另一个线程结束后再去执行，就是使当前线程可以阻塞其他线程执行。

Thread.join()是将指定的线程加到当前线程将链各个交替执行的线程合并为顺序执行的线程。

跨域的流程

分布式事务

本地事务：是用关系数据库来控制事务，关系数据库通常都是具有ACID特性的，传统的单体应用通常会将数据全部存储在一个数据库中会借助关系数据库来完成事务控制。

分布式事务：分布式系统中一次操作由多个系统协同完成这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。这里强调的是多个系统通过网络协同完成一个事务的过程并不是强调多个系统访问了不同的数据库，即使多个系统访问的是同一个数据库也是分布式事务，如下图：

另外一种分布式事务表现是一个应用程序使用多个数据源连接不同的数据库当一次事务需要操作多个数据源此时也是属于分布式事务，

第一种分布式事务用的较多。

分布式事务的场景：

MVCC和可重复读

MVCC包含三个概念：隐藏列，undo log，ReadView

隐藏列：InnoDB引擎中每个数据表都有两个隐藏列(还有一个隐藏id)，分别是trx_id，创建版本号和roll-pointer(回滚指针)。其中创建版本号其实就是创建该行数据的事务id，这些隐藏列对客户端是不可见的。

undo log：事务对数据行进行一次更新操作时，会把旧数据行记录在一个叫做undo log的记录中，ndo log中除了记录数据行，还会记录下该行数据的对应的创建版本号就是生成事务id，将原来的数据行中的回滚指针指向undo log记录中的这行数据。在原来数据表中进行一次更新操作，如果这次更新操作回滚了，那么就可以根据回滚指针去undo log中查找之前的数据进行复原。如果后续还有更新操作的话，就会在undo log中和之前的数据行形成一条链表，链表头就是最新的数据，这条链表就叫做版本链。

事务的可见性是基于undo log来实现的。

ReadView：进行查询操作时事务会生成一个ReadView，ReadView是一个事务快照准确来说是当前时间点系统内活跃的事务列表，就是说系统内所有未提交的事务都会记录在Readview内，事务就根据它来判断哪些数据是可见哪些是不可见的。

查询一条数据时候事务会拿到ReadView去undo log中进行判断，如果查到某一跳数据：

• 先去查看undo log中的最新数据行，如果数据航的版本号小于ReadView记录的事务id最小值，就是说明这条数据对当前数据库是可见的可以直接作为结果集返回；
• 如果数据航版本号大于ReadView记录的最大值，说明这条数据是由一个新的事务修改的对当前事务不可见，那么顺着版本链往下寻找第一条满足条件的；
• 如果数据行版本号在ReadView最小值和最大值之间，那么就需要好进行遍历整个ReadView，如果数据行版本号等于ReadView的某个值，说明该行数据仍然处于活跃状态对当前事务就是不可见的。

ReadView就是这样来判断数据可见性的。

对读已提交来说，事务中的每次读操作都会生成一个新的ReadView，如果这期间某个事务提交了那么它就会从ReadView中移除。这样确保事务每次读操作都能读到相对比较新的数据。

对可重复读来说，事务只有在第一次进行读操作时才会生成一个ReadView，后续的读操作都会重复使用这个ReadView。也就是说，如果在此期间有其他事务提交了，那么对于可重复读来说也是不可见的，因为对它来说事务活跃状态在第一次进行读操作时就已经确定下来后面不会再进行修改。

Cookie和Session

1. cookie数据信息存放在客户端浏览器上，session数据信息存放在服务器上；
2. 单个cookie保存的数据小于等于4KB，一个站点最多保存20个cookie；对于session来说没有上限，但是出于堆服务器端的性能考虑session内尽量不要存放过多的东西并且要设置session删除机制；
3. cookie中只能保存ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据；session中能够存储任何类型的数据，包括且不限于string、integer、list等；
4. cookie对客户端是可见的是不安全的，session存储在服务器上对客户端是透明的不存在敏感信息泄露的危险；
5. cookie保管在客户端不占用服务器资源并发大的网站是个很好的选择；session保存在服务器端每个用户产生一个session，并发访问的用户很多占用很多的session耗费大量内存；
6. cookie支持跨域访问，session不支持跨域访问；
7. 开发通过设置cookie属性达到使cookie长期有效的效果；session依赖JSESSIONID的cookie，而cookie JSESSIONID过期时间默认是-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果

submit原理

• 创建线程池的时候,可以使用executors的静态方法,也可以使用new ThreadPoolExecutor的方式手动创建线程池,通过在线程池中指定参数达到创建不同类型的线程池的效果；
• executors底层其实也是调用的new ThreadPoolExecutor()的方式创建的,是对不同线程池的封装；
• 线程的执行有两种方式,一种是submit(runnable v)的形式,一种是execute(runnable b) 的形式,不同的是submit可以返回一个future的实现类,相同的一点是submit底层其实也是调用的execute；
• 调用execute方法,首先判断传入的参数是否为空,如果为空抛出异常,如果不为空使用获取ctl值,计算出当前线程状态码,通过状态码计算出当前线程池工作线程是否小于核心线程数量；
• 如果小于,判断添加工作线程操作是否正常,如果正常,直接返回,如果不正常,继续执行获取ctl值,在添加工作线程的过程中,首先通过循环的方式保证ctl在加1的情况下状态同步,如果不同步,一直循环到同步为止,添加完成后,创建线程工作对象,把工作线程添加到set集合中,并执行.start,如果执行不成功,从set中删除添加的worker对象,并且ctl回滚到之前没有自增的值.
• 如果上述中添加工作线程失败,或者当前线程池中工作线程数量操作和信息数量,执行下列逻辑；
• 判断当前线程池是否是running状态：
  (1)、如果不是running状态,或者是running状态,并且添加到线程队列失败,重新添加个工作线程,此时入参中第二个参数用于添加工作线程的逻辑中当前工作线程数量与最大线程数量做对比,如果添加失败,执行reject处理类处理；
  (2)、如果是running状态,并且添加队列成功,重新获取ctl值,判断当前线程池状态如果是不是running状态,并且从对象中删除成功,则当前线程交给拒绝线程处理器处理,如果不满足上面条件,判断当前线程池的工作线程数如果为0,重新添加一个不带任务的线程。

MyBatis缓存机制

MyBatis和同是持久层的hibernate一样，都存在着缓存机制。

MyBatis缓存机制有两级：
(1)一级缓存：
缓存存在要求：同一个SqlSession中，在没有收到改变该数据的请求之前
缓存失效条件：不是同一个sqlsession对象，查询过程中两次的查询条件不同，两次之间进行CRUD操作，两次之间手动清空缓存

(2)二级缓存：
作用：推挤缓存是基于同一个SqlSesion类的实例对象的。但是有些时候在web工厂中将会执行查询操作的方法分装在某个Service方法中，当查询完一次后Service方法结束，此时SqlSession类的实例对象就会关闭，一级缓存就会被清空。此时若再次调用用Service方法查询同一个信息，此时异界缓存就是空的从而无法从缓存中获取信息！

因此可以使用二级缓存，二级缓存存在与Mapper实例中，当多个SqlSession类的实例对象加载相同的mapper文件，并执行其中国的SQL配置时，他们就共享一个Mapper缓存。当某个SqlSession类的实例对象执行增，删，改，等改变数据的操作时，Mapper实例都会清空其二级缓存！