Spring框架根据bean是否实现接口决定使用何种AOP实现:
如果bean实现了接口则使用JDK动态代理对bean进行增强,
如果bean没有实现接口则使用CGLib对bean进行增强。
二者均生成了代理对象。
Cglib调用目标对象时,不是直接调用的目标对象,而是通过cglib创建
的代理对象调用的目标对象。
Read_uncommitted 读未提交 会发生脏读,读到未提交的数据
read_committed 读提交 会发生不可重复读 事务未提交,可能多次读取数据不一致
repeatable_read 可重复度 会发生幻读 读到别人提交的记录
序列化是级别最高的,所有事务串行
脏读 是在读未提交发生的,在自己的事务里读到别人事务未提交事务 不可重复读,是在读提交级别发生的,别人事务在 update 数据, 在自己的事务中读到别人更新前后的数据,导致多次 读取不一致 幻读,是在 可重复度发生的,别人的事务在insert delete数据,在自己的事务中,多次读取数据不一致 丢失更新,两个事务更新一行数据,后面的把前面的覆盖了
乐观锁,可以看做是CAS操作
https://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw==&mid=2247486906&idx=1&sn=446a14eb8a66772965130eb3cc4302b7&chksm=eb53888cdc24019af40832a42059aac6901abe78b0b0b8ab0d8f5cfac62f6e984ce85cf40fa2&scene=0#rd
hashCode是jdk根据对象的地址算出来的一个int数字,即对象的哈希码值,代表了该对象在内存中的存储位置。
我们都知道hashCode()方法是顶级类Object类的提供的一个方法,所有的类都可以进行对hashCode方法重写。
我们也知道在比较一个类是否相同时往往会重写equals方法,值得注意的是,重写equals方法的同时必须也要重写hashCode方法,多次调用一个对象的hashCode方法必须返回同一个数字,这也是必须遵守的规范,不然会造必须存在的危害。
当两个对象equals相同,hashCode规定也必须相同,但反过来就不一定,两个对象对应一个hashCode,但equals却并不相等。。这就是传说中的hash冲突。HashMap是以hashCode取模数组形式存放值的,那两个对象hashCode一样会不会造成前一个对象的值覆盖呢?答案是不会,因为它采用了另外一种链表数据结构来解决hash冲突的情况,即使两个对象的hashCode一样,它们会放到当前数组索引位置的链表中。
HashSet通过HashMap来实现的,用来存储不重复数据的,怎么判断里面的对象是否重复呢?判断对象是否重复即是判断对象里面的属性是否都一样,这时必须是重写了equals方法去比较对象的里面所有的值,而不是比较引用地址,比较引用地址它们永远都不相等,除非是同一个对象。通过equals比较的过程性能是非常不佳的,所以有了hashCode这个设计,简单两个数字的比较性equals没法比的,所以可以先通过比较对象的hashCode是否一样确定是不是同一个对象,如果hashCode不一样这时肯定就不是同一个对象,反之如果hashCode一样而且equals或者也一样这肯定就是同一个对象。所以先比较数字的hashCode再比较equals或者,这样效率会明显提升。
假如我们重写了equals而不重写hashCode方法,多个对象属性值一样的它们的hashCode肯定是不一样的,这时作为key在put到map中的时候,就会有多个这样的key,而达不到对象作为key的场景,同样也达不到HashSet去重的效果。