|
|
@@ -88,8 +88,10 @@ tags:
|
|
|
底层数据结构为哈希表/散列表,是一个元素为链表的数组,链表中的Node包括hash,key,value,next
|
|
|
hashmap是非线程安全的,因为put的时候有个扩容操作,会有一个复制数组的操作,有可能会操作旧的数组
|
|
|
jdk8对hashmap加入了红黑树,在链表的长度>8的时候会进行一个红黑树的转换
|
|
|
- hashtable是线程安全的,get与put操作都是用synchronized实现的
|
|
|
- ConcurrentHashMap是线程安全的;jdk1.7采用ReentrantLock;jdk1.8采用CAS+Synchronized只针对put上锁,get不上锁,因为Node的成员val是用volatile修饰
|
|
|
+ hashtable是线程安全的,get与put操作都是用synchronized实现的,会锁住整个表.
|
|
|
+ ConcurrentHashMap是线程安全的
|
|
|
+ jdk1.7采用ReentrantLock锁住每个segment;
|
|
|
+ jdk1.8采用CAS+Synchronized只针对put上锁,如果key对应的元素不存在,则通过CAS进行操作,否则使用synchronized进行操作;get不上锁,因为Node的成员val是用volatile修饰.
|
|
|
这也是它比其他并发集合比如hashtable、用Collections.synchronizedMap()包装的hashmap安全效率高的原因之一。
|
|
|
```
|
|
|
- synchronized和ReentrantLock区别
|
|
|
@@ -98,7 +100,7 @@ tags:
|
|
|
都是可重入锁/递归锁,指的是同一线程外层函数获得锁之后，内层递归函数仍然有获取该锁的代码，但不受影响。
|
|
|
锁的实现：
|
|
|
Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，前者的实现是比较难见到的，后者有直接的源码可供阅读。
|
|
|
- 性能的区别：
|
|
|
+ 性能区别：
|
|
|
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，
|
|
|
两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的
|
|
|
CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。
|
|
|
@@ -118,6 +120,12 @@ tags:
|
|
|
等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
|
|
|
但是线程自旋是需要消耗cpu的，说白了就是让cpu在做无用功，线程不能一直占用cpu自旋做无用功，所以需要设定一个自旋等待的最大时间。
|
|
|
```
|
|
|
+- equals和==的区别
|
|
|
+ ```
|
|
|
+ ==：是一个比较运算符,基本类型比较的是值,引用类型比较的是地址值(是否为同一个对象的引用).
|
|
|
+ equals：是Object类的一个方法,只能比较引用类型,重写前比较的是地址值,重写后一般是比较对象的属性.
|
|
|
+ ```
|
|
|
+
|
|
|
|
|
|
### 并发编程专题
|
|
|
|
|
|
@@ -190,6 +198,17 @@ tags:
|
|
|
SynchronousQueue：并发同步阻塞队列
|
|
|
SynchronousQueue队列内部仅允许容纳一个元素。当一个线程插入一个元素后会被阻塞，除非这个元素被另一个线程消费。
|
|
|
```
|
|
|
+- 线程间通信
|
|
|
+ ```
|
|
|
+ 多个线程处理同一资源(共享数据),但是任务(处理方式)却不同.
|
|
|
+ 等待唤醒机制
|
|
|
+ Object类提供了3个方法：
|
|
|
+ wait(): 让线程处于等待状态，被wait的线程会被存储到线程池中。
|
|
|
+ notify(): 唤醒线程池中一个线程(任意)。如果对象调用了notify方法就会通知某个正在等待这个对象的控制权的线程可以继续运行。
|
|
|
+ notifyAll(): 唤醒线程池中的所有线程。如果对象调用了notifyAll方法就会通知所有等待这个对象控制权的线程继续运行。
|
|
|
+ 以上方法为什么定义在Object类中?
|
|
|
+ 这些方法的调用必需通过锁对象调用,而锁对象有可能是任意对象,所以这些方法必须定义在Object类中.
|
|
|
+ ```
|
|
|
|
|
|
### 性能调优专题
|
|
|
|
|
|
@@ -215,6 +234,20 @@ tags:
|
|
|
|
|
|
### 数据结构与算法专题
|
|
|
|
|
|
+- B树(B-树)与B+树的区别
|
|
|
+ ```
|
|
|
+ B树与B+树的出现是为了减少磁盘IO的次数,基本思想就是
|
|
|
+ 降低树的深度,每个节点存储多个元素
|
|
|
+ 摒弃二叉树结构,采用多叉树
|
|
|
+ B树：也平衡多路查找树
|
|
|
+ 每个节点都存储key和data,所有节点组成这颗树,并且叶子节点指针为null.
|
|
|
+ B+树：
|
|
|
+ 只有叶子节点存储data,叶子节点包含了这棵树的所有键值,叶子节点不存储指针.
|
|
|
+ 这意味着相同大小的磁盘页每个节点可以存储更多元素,使得查询的IO次数更少.
|
|
|
+ 每个叶子节点增加了顺序访问指针(一个指向相邻叶子节点的指针).
|
|
|
+ 使得所有节点形成有序链表,便于范围查询,这样一棵树成了数据库系统实现索引的首选数据结构。
|
|
|
+ ```
|
|
|
+
|
|
|
### 设计模式专题
|
|
|
|
|
|
- 如何高效实现单例设计模式
|
|
|
@@ -281,6 +314,7 @@ tags:
|
|
|
CAP理论：
|
|
|
开发大规模分布式系统会遇到一致性,可用性,分区容错性3个特性,而一个分布式系统最多只能满足其中的2项.而分区容错性是分布式系统
|
|
|
必然要面对和解决的问题,因此我们要根据业务特点在一致性和可用性之间寻求平衡.
|
|
|
+ 分区容错性：在任意分区网络故障的情况下系统仍能继续运行
|
|
|
BASE理论：
|
|
|
基本可用：指分布式系统在出现不可预知故障的时候,允许损失部分可用性.
|
|
|
软状态：允许系统中的数据存在中间状态,即允许数据同步的过程中存在延时.
|
|
|
@@ -291,14 +325,16 @@ tags:
|
|
|
try：完成所有业务检查(一致性),预留业务资源(准隔离性)
|
|
|
confrim：确认执行业务操作,不做任务业务检查,只使用try阶段预留的业务资源
|
|
|
cancel：取消try阶段预留的业务资源
|
|
|
- 开源框架实现：atomikos商业版,tcc-transaction,spring-cloud-rest-tcc,支付宝tcc
|
|
|
+ 开源框架实现：atomikos商业版,tcc-transaction,spring-cloud-rest-tcc,支付宝tcc(XTS)
|
|
|
+ 分布式事务框架主要是帮我们解决了第二阶段的自动化;充当了一个协调器,根据预留操作的返回结果来自动化调用提交/取消操作.
|
|
|
+ 可靠消息最终一致性方案：
|
|
|
+ 基于RocketMQ：存在中间状态
|
|
|
+ 基于普通消息队列：不存在中间状态,自己单独写个服务来实现中间状态
|
|
|
TCC与XA对比：
|
|
|
XA是资源(数据库)层面的分布式事务,强一致性,在两阶段提交的整个过程中,一直会持有资源的锁.
|
|
|
TCC是业务层面的分布式事务,最终一致性,不会一直持有资源的锁.针对整个系统提升了性能.
|
|
|
-
|
|
|
```
|
|
|
|
|
|
-
|
|
|
## 参考链接
|
|
|
|
|
|
## 结束语
|
lvzq