2022.02.14 周一 雾

一、ReetrantLock

1. ReetrantLock基于内部类FairSync(公平锁)和NonFairSync(非公平锁)实现。可重入性是基于Thread.currentThread()实现。

2. 公平和非公平锁的队列都基于锁内部维护的一个双向链表，表结点Node的值就是每一个请求当前锁的线程。公平锁则在于每次都是依次从队首取值。

3. 公平锁和非公平锁都是排他锁。（注：共享锁（读锁），事务A给数据加了共享锁后，其它事务只可以再加共享锁，不能加排他锁；排他锁（写锁））

4. ReentrantLock 的公平锁和非公平锁都委托了AbstractQueuedSynchronizer#acquire去请求获取。

5. ReentrantLock 对线程的阻塞是基于 LockSupport.park(this); (见 AbstractQueuedSynchronizer#parkAndCheckInterrupt)。 先决条件是当前节点有限次尝试获取锁失败。

6. state使用volatile修饰

二、ReetrantReadWriteLock

1. ReadLock和WriteLock两个实现Lock接口的内部类

2. 构造方法默认非公平，可以传入参数创建公平的

3. sync 继承自AQS，sync有两个内部类HoldCounter（读锁）和ThreadLocalHoldCounter， ThreadLocalCounter重写了ThreadLocalCounter的initialValue

三、Condition

1. Lock.newCondition()获取Condition对象，condition.await，condition.signal，condition.signalAll()。

2. sync的内部类ConditionObject实现了condition接口。

四、@transactional

1. 可以用类似"propagation=REQUIRED"这种方式自定义传播机制，总共7种，默认为required，也就是使用已有的事务，没有就新建一个事务。

2. 事务失效的情况

1. 未启用spring事务管理功能@EnableTransactionManagement
2. 方法不是public类型的
3. 数据源未配置事务管理器
4. 自身调用问题
5. 异常类型错误
6. 异常被吞了
7. 业务和spring事务代码必须在一个线程中

3. 事务的原理

spring是通过aop的方式，对需要spring管理事务的bean生成了代理对象，然后通过代理对象拦截了目标方法的执行，在方法前后添加了事务的功能，

所以必须通过代理对象调用目标方法的时候，事务才会起效。

五、索引

1） 失效的情况

1.有or必全有索引;
2.复合索引未用左列字段;
3.like以%开头;
4.需要类型转换;
5.where中索引列有运算;
6.where中索引列使用了函数;
7.如果mysql觉得全表扫描更快时（数据少）

2）没必要加索引的情况

1.唯一性差;
2.频繁更新的字段不用（更新索引消耗）;
3.where中不用的字段;
4.索引使用<>时，效果一般;

六、redis

1. 哨兵模式，最少三台机器：Master、Slave、Sentinel

2. 集群模式16384个槽点

3. 为什么快：基于内存、非阻塞多路IO、单线程、乐观锁、专门设计的数据结构、底层模型vm机制、优秀的过期策略

4. Redis并没有使用C语言的字符串，而是使用了简单动态字符串(SDS)。相对于C语言的字符串来讲，SDS记录了自身使用和未使用的长度，

时间复杂度为O(1),而C语言则要遍历整个空间，时间复杂度为O(N)

5. Redis的链表为双端链表，链表节点带有perv和next指针，链表还带有head和tail指针，使得获取链表某节点前后置节点的时间复杂度都是O(1)。

并且Redis链表无环，prev和next指针指向null，对链表的访问以null作为截至的判断条件。
 链表中有记录自身长度的属性len，并且链表使用void*指针来保存节点值，可以通过list 结构的dup、free、match三个属性为节点值设置类型特定函数，

所以链表可以用来保存各种不同类型的值。