JVM内存模型和性能优化 转

JVM内存模型和性能优化

JVM内存模型优势

1. 内置基于内存的并发模型：      多线程机制
2. 同步锁Synchronization
3. 大量线程安全型库包支持
4. 基于内存的并发机制，粒度灵活控制，灵活度高于数据库锁。
5. 多核并行计算模型
6. 基于线程的异步模型。

---

JVM性能的人为问题

1. 关键缘由是：没有正确处理好对象的生命周期。
2. 须要从需求中找出存在天然边界的业务对象，将其对应落实到内存中，成为内存模型In-memory Domain Model。
3. 有大小边界限制的内存是缓存，没有永远使用不完的内存，缓存=“有边界的”内存。
4. 缓存是Domain Model对象缓存，不一样于传统意义上数据库缓存的定义。
5. 分布式缓存能够提升巨量数据处理计算能力。

---

Java内存种类

1. Stack栈内存
   存取速度快，数据可多线程间共享。 
   存在栈中的数据大小与生存期必须肯定
2. Heap堆内存
      大小动态变化，对象的生命周期没必要事先告诉编译器JVM。

两种内存使用

1. Stack栈内存 
   基本数据类型，Java  指令代码，常量 
   对象实例的引用 对象的方法代码
2. Heap堆内存
      对象实例的属性数据和数组。堆内存由Java虚拟机的自动垃圾回收器来管理。

---

对象如何保存在内存中？

1. 对象的属性Attribute Property

    属性值做为数据，保存在数据区heap 中，包括属性的类型Classtype和对象自己的类型

1. 方法method

   方法自己是指令的操做码，保存在stack中。 
   方法内部变量做为指令的操做数也是在Stack中， 
    包括基本类型和其余对象的引用。

1. 对象实例在heap 中分配好内存之后，须要在stack中保存一个4字节的heap内存地址，用来定位该对象实例在heap 中的位置，便于找到该对象实例。

---

静态属性和方法的特色

1. 静态属性和方法都是保存在Stack中，
2. Stack内存是共享的，其余线程均可以访问静态属性实际是全局变量。
3. 静态方法在Stack，就没法访问Heap中的数据。静态方法没法访问普通对象中数据。

1. 静态属性意味着全局变量，生命周期和JVM一致。JVM属于技术边界，静态只能用于技术边界内工具性质使用，不能用做业务。

---

内存管理：垃圾回收机制

1. 每一种垃圾收集的算法（引用计数、复制、标记-清除和标记-整理等）在特定条件下都有其优势和缺点。
2. 当有不少对象成为垃圾时，复制能够作得很好，可是复制许多生命周期长的对象时它就变得很糟（要反复复制它们）。
3. 标记-整理适合生命周期长对象能够作得很好（只复制一次），可是不适合短生命的对象。
4. Sun JVM 1.2 及之后版本使用的技术称为 分代垃圾收集（generational garbage collection）,它结合了这两种技术以结合两者的长处。

---

可选用的GC类型

---

JVM性能优化

1. 内存微调优化

1. 锁争夺微调:

  多线程 不变性 单写原则 Actor Disrupotor

1. CPU使用率微调

1. I/O 微调

---

内存微调优化

1. 内存分配：

   新生代 Eden和survior  旧生代内存大小分配。 
   内存越大，吞吐量越大，可是须要内存整理的时间就越长，响应时间有延迟。

1. 垃圾回收机制

   垃圾回收启动整个应用都暂停，暂停时间形成响应时间有延迟。

---

 

 

内存微调目标

 

1. 在延迟性(响应时间)和吞吐量上取得一个平衡。

1. 内存大小影响吞吐量和延迟性。须要在内存大小和响应时间之间取得一个平衡。

1. 垃圾回收机制是延迟的最大问题。目标尽可能不启动，少启动。

---

 

内存模型

新生代Eden内存分配

• 新生代(New Generation )：Eden + 1 Survivor。全部新建立的对象在Eden。
• 当Eden满了，启动Stop-The-World的GC，或为minor gc，采起数次复制Copy-Collection到Survivor。
• 通过几回收集，寿命不断延长的对象从Survivor 进入老生代，也称为进入保有Tenuring，相似普通缓存LRU算法。

survivor设计要旨

1. 足够大到能容纳全部请求响应中涉及的对象数据。

1. 每一个survivor空间也要足够大到可以容纳活跃的请求对象和保有对象。

1. Survivor大小决定了保有Tenuring阀值，阀值若是能大到容纳全部常住对象，那么保有迁移过程就越快。

老生代Old

1. 老生代的gc称为major gc，就是一般说的full gc。
2. 采用标记-整理算法。因为老年区域比较大，并且一般对象生命周期都比较长，标记-整理须要必定时间。因此这部分的gc时间比较长。
3. minor gc可能引起full gc。当eden＋from space的空间大于老生代的剩余空间时，会引起full gc。这是悲观算法，要确保eden＋from space的对象若是都存活，必须有足够的老生代空间存放这些对象。
4. 这些都根据状况调整启动JVM的设置。
5. 使用 Adaptive让JVM自动划分新生代和老生代。

Permanent Generation 永久代

1. 该区域比较稳定，主要用于存放classloader信息，好比类信息和method信息。
2. 缺省是 64M ，若是你的代码量很大，容易出现OutOfMemoryError: PermGen space 。
3. 2G以上内存设置MaxPermSize为160M
4. -XX:PermSize=128m -XX:MaxPermSize=160m

---

下降Full GC发生几率

1. 为了下降Full GC发生几率，若是下降了老生代大小，那么 OutOfMemoryError 发生，Full GC几率反而会上升。
2. 若是为了下降Full GC，增长老生代大小，执行时间可能会被延长。
3. 必须寻找合适大小的老生代。
4. 避免大的对象迁移到老生代。
5. 减小迁移到老生代的对象数目

---

java.lang.OutOfMemoryError

1. （1）在高负荷的状况下的却须要很大的内存，所以能够经过修改JVM参数来增长Java Heap Memory。
2. （2）应用程序使用对象或者资源没有释放，致使内存消耗持续增长，关键采起OO封装边界方式，树立对象都有生命周期的基本习惯。
3. （3）再一种也多是对于第三方开源项目中资源释放了解不够致使使用之后资源没有释放（例如JDBC的ResultSet等）。

---

JVM参数

1. -Xms, -Xmx—定义JVM的heap大小最小和最大值。

1. -XX:NewSize— 定义年轻态的最小大小，Eden越大越好，可是越大响应有延迟。

 

1. -Xmx2G -Xms1G -XX:NewSIze=512M (OldGen at least 1G)
2. -Xmx3G -Xms1G -XX:NewSize=512M (OldGen at least 2G)
3. Xmx4G -Xms2G -XX:NewSize=1G (OldGen at least 2.5G)
4. -Xmx6G -Xms3G -XX:NewSize=2G (OldGen at least 3.5G)
5. -Xmx8G -Xms4G -XX:NewSize=3G (OldGen at least 4.5G)

参数调整示意

1. JAVA_OPTS="$JAVA_OPTS -server -Xss1280K -Xms1664m -Xmx1664m  -XX:MaxPermSize=128m -XX:SurvivorRatio=16  -XX:NewSize=1280m  -XX:MaxNewSize=1280m -XX:+DisableExplicitGC -XX:GCTimeRatio=2 -XX:ParallelGCThreads=4 -XX:+UseParNewGC -XX:MaxGCPauseMillis=2000 -XX:+UseConcMarkSweepGC  -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled

---

Survivor大小

1. NewSize / ( SurvivorRatio + 2）
2. 若是SurvivorRatio =16， NewSize =1280m，那么S大小是70M。
3. 过小，溢出的复制Collection进入老生代。
4. 太大，闲置无用 浪费内存。
5. 使用XX:+PrintTenuringDistribution  和-XX:+PrintGCDetails, -XX:+PrintHeapAtGC观察：
6. 与 -XX:+UseAdaptiveSizePolicy 冲突

 

---

垃圾回收机制启动

1. 垃圾回收机制不会频繁启动，由于机制一旦启动，形成应用程序停顿。
2. 机制通常内存剩余5%左右启动，因此有现象：启动服务器，内存不断消耗，有多大内存消耗多大。
3. 问题：若是服务器程序频繁触及5%底线，机制频繁启动，形成服务器慢..甚至死机。
4. 根源：应用程序无限制频繁大量建立对象，消耗内存。

---

控制垃圾回收

1. 带CMS参数的都是和并发回收相关的
2. -XX:+UseParNewGC，对新生代采用多线程并行回收。
3. CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS）
4. 用jmap和jstack查看

---

串行 并行回收的区别

1. 新生代 高吞吐量：
2. -XX:+UseSerialGC
   -XX:+UseParallelGC
   -XX:+UseParNewGC
3. 老生代 低暂停：
4. -XX:+UseParallelOldGC
   -XX:+UseConcMarkSweepGC
5. 相同点：GC时都暂停一切。
6. 不一样点：一个线程和多个线程同时GC

并行和CMS（Concurrent-Mark-Sweep）区别

1. CMS步骤：
2. - initial mark
   - concurrent marking
   - remark
   - concurrent sweeping
3. 区别：CMS一个线程，并行多个线程
4. CMS只是在1 3阶段暂停，而并行所有暂停。

 Parallel GC 和 CMS GC

1. 压实compaction是移除内存碎片，也就是移除已经分配的内存之间的空白空间。
2. 在Parallel GC中，不管Full GC是否执行，压实老是被执行，会花费更多时间，不过在执行完Full GC后，内存也许再被使用时，会分配得快些，可以顺序分配了。
3. CMS GC 并不执行压实，因此更快，碎片太多，没有空间放置大的须要连续空间的对象，“Concurrent mode failure”会发生。

---

并行和CMS配置

1. -XX:UserParNewGC 适合于

  新生代 (multiple GC threads)
-XX:+UseConcMarkSweepGC  适合于
  老生代 (one GC thread, freezes the JVM only during the initial mark and remark phases) 
  -XX:InitiatingOccupancyFraction 80是表示CMS是在老生代接近满80%启动，如CPU空闲，可设定点一些。

  -XX:+CMSIncrementalMode 用于CMS，不会让处理器Hold住整个并发phases  。

 

高吞吐量调整

1. UseParallelGC 和UseParNewGC等高吞吐量配合参数：

1. -XX:+UseAdaptiveSizePolicy
2. -XX:MaxGCPauseMillis=… (i.e. 100)
3. -XX:GCTimeRatio=… (i.e. 19)

UseAdaptiveSizePolicy

1. 当使用-XX:+UseParallelGC 缺省策略加载，XX:+UseAdaptiveSizePolicy。
2. 主要调整下面参数，在暂停和吞吐量之间取得一个平衡：
3. 一个合适的最大GC暂停值
4. 一个合适的应用程序吞吐量值
5. 最小化实现路径。

UseAdaptiveSizePolicy 策略路径

1. 若是GC暂停时间大于目标暂停时间（-XX:MaxGCPauseMillis=nnn ），下降新生代大小以匹配目标暂停时间。
2. 若是暂停时间合适，考虑应用的吞吐量，经过增大新生代的大小知足吞吐量。
3. 若是暂停时间和吞吐量两个目标都知足，新生代大小下降以节约成本路径。

UseAdaptiveSizePolicy

1. -XX:MaxGCPauseMillis=nnn ：不能设置太小，会阻碍吞吐量，若是不设置，暂停时间依赖heap中活动数据量。

1. -XX:GCTimeRatio=nnn 不超过应用运行时间的1 / (1 + nnn) 用在垃圾回收上。缺省99。垃圾回收时间不该该超过总体时间的1%

---

JVM微调调试方法

1. 配置JVM的JAVA_OPTS参数 –verbosegc
2. 观察Full GC的信息输出：
3. [Full GC $before->$after($total), $time secs]
4. Full GC太频繁，应用暂停，响应时间受影响。
5. 克服GC太频繁方法：
6. 1. 增大内存。增大年轻代的内存
7. 2.使用LRU等缓存，限制大量对象建立。
8. 3. 64位下压缩对象头。
9. 消灭Full GC：-XX:+PrintGCDetails 无Full GC输出

内存大小影响

1. 大内存：

       1. 下降GC执行次数。 
        2.增长每次GC执行的时间。

1. 小内存：

        1.增长了GC执行次数 
         2.下降每次GC执行的时间。

若是Full GC可以在1秒内完成，10G也是合适的。

---

Jstat 监视微调

1. jstat -gcutil 21891 250 7
2. 21891是Java的pid, 250表示间隔几秒  7表示采样7次
3. S0      S1     E      O    P      YGC  YGCT FGC FGCT   GCT
   12.44 0.00 27.20 9.49 96.70 78 0.176 5 0.495 0.672
   12.44 0.00 62.16 9.49 96.70 78 0.176 5 0.495 0.672
   12.44 0.00 83.97 9.49 96.70 78 0.176 5 0.495 0.672
   0.00 7.74 0.00 9.51 96.70 79 0.177 5 0.495 0.673
   0.00 7.74 23.37 9.51 96.70 79 0.177 5 0.495 0.673
   0.00 7.74 43.82 9.51 96.70 79 0.177 5 0.495 0.673
   0.00 7.74 58.11 9.51 96.71 79 0.177 5 0.495 0.673
4. Minor GC :YGC年轻代GC发生了78次，YGCT是GC发生的时间累计0.176。
5. FULL GC发生了5次，累计0.495， 每次是0.495/5
6. http://www.cubrid.org/blog/dev-platform/how-to-monitor-java-garbage-collection/
7. 若是GC执行时间在一秒以上，须要GC微调，若是在0.1-0.3之间则不须要

须要微调的案例

1. Full GC超过一秒，须要微调。
2. Minor GC正常

 

 

 

 

---

 

微调前检查内存大小分配

1. jstat –gccapacity
2. NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
3. 212992.0 212992.0 212992.0 21248.0 21248.0 170496.0 1884160.0 1884160.0 1884160.0 1884160.0 262144.0 262144.0 262144.0 262144.0 54 5
4. 新生代是 212,992 KB，老生代是1,884,160 KB
5. 新生代:老生代是1:9， 调整NewRatio
6. NewRatio=2
7. NewRatio=3
8. NewRatio=4
9. 若是其中一个设置没有FULL GC发生，就是合适新生代和老生代的大小。

1. 随着新生代内存减少，其GC时间缩短：
2. NewRatio=2: 45 ms
3. NewRatio=3: 34 ms
4. NewRatio=4: 30 ms
5. 内存输出结构：
6. S0 S1 E O P YGC YGCT FGC FGCT GCT
7. 8.61 0.00 30.67 24.62 22.38 2424 30.219 0 0.000 30.219
8. 年轻代发生了2424次，而FullGC没有一次发生，存在大量临时对象都是新生代毁灭。

---

Jstat参数说明

 

---

JVM优化参数

1. JAVA_OPTS="$JAVA_OPTS  -verbose:gc  -XX:+PrintGCDetails -XX:+PrintTenuringDistribution  -Xloggc:/home/jdon/jdongc.log  -server -Xms1536m -Xmx1664m -XX:NewSize=768m  -XX:MaxNewSize=896m -XX:+UseAdaptiveGCBoundary  -XX:MaxGCPauseMillis=250 -XX:+UseAdaptiveSizePolicy  -XX:+DisableExplicitGC -XX:ParallelGCThreads=4 -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode  -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled
2. 最大新生代GC暂停时间是250毫秒，在这个基础上JVM自动调整尽可能知足吞吐量。
3. [GC 2016.468: [ASParNew: 686991K->42743K(711316K), 0.1310080 secs] 713706K->74888K(1422668K) icms_dc=0 , 0.1324500 secs]
4. S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  
5.   0.00  64.80  93.53   4.52  66.34      7    0.619     7    2.381    3.000

---

若是响应时间仍是不够快？

1. 响应延迟和吞吐量是一对矛盾，而吞吐量主要标志是内存大小。

1. 下降NewSize大小, 下降survivor空间。
2. 下降进入老生代reduce的门槛，由于缓存Hold住大量长生命对象，让这些对象进口进入老生代。而老生代的CMS不多暂停。

 

CMS

1. CMS并不进行内存压实compact，因此，会致使碎片。而碎片也会致使暂停。

1. Apache Cassandra使用 slab allocator。
2. 每一个Slab是2M；
3. 用compare-and-set拷贝他们。
4. 三天

G1 vs CMS vs Parallel GC

　　三个垃圾回收机制的比较，语法以下：

• -XX:+UseParallelOldGC
• -XX:+UseConcMarkSweepGC
• -XX:+UseG1GC

　　使用GCViewer观察，结果以下 单位是毫秒：

 

	Parallel	CMS	G1
Total GC pauses	20 930	18 870	62 000
Max GC pause	721	64	50

 

并行GC （ - XX：+ UseParallelOldGC ） 。在30多分钟的测试时间内，用并行收集器 GC暂停花了接近21秒。最长停顿了721毫秒。所以，咱们以此为基准： GC下降了吞吐量为总运行时间的1.1 ％。最坏状况下的延迟为721ms 。

CMS （ - XX：+ UseConcMarkSweepGC ） 一样30分钟，由于GC咱们失去了不到19秒 。相比并行GC吞吐量明智的。延迟另外一方面已显著改善 - 最坏状况下的延迟时间减小10倍以上！来自GC的最大暂停时间咱们如今面临的只是64ms。

最闪亮的GC算法 - G1 （ - XX：+ UseG1GC ） 。在一样的测试，，咱们看到的结果吞吐量问题比较严重。这一次，咱们的应用程序花费超过一分钟等待GC来完成。比较这与CMS中的开销只有1％ ，咱们如今面对接近的吞吐量3.5 ％的效果。但若是你真的不关心的吞吐量，而是想挤出最后那么一点延迟 - 比CMS提升20％左右 - 用G1看到的最长GC暂停服用仅50毫秒。

结论：CMS仍然是最好的“默认”选项。 G1的吞吐量仍然差那么多，获得的延迟一般是不值得的。

JVM推荐设置

 

Heap size	Total GC pauses GC暂停	Throughput吞吐量
-Xmx300m	207.48s	92.25%
-Xmx384m	54.13s	97.97%
-Xmx720m	20.52s	99.11%
-Xmx1,440m	*11.37s	*99.55%

对象和Java多线程

1. 缺省对象都是继承java.lang.Object

1. 也能够特别继承java.lang.Thread ；

 

1. 或实现java.lang.Runnable接口

1. 对象的方法以线程方式执行。

---

 

线程的主内存和工做内存

1. 主内存对于全部线程可见的。主内存通常在Heap中，对象的属性值是放在Heap中。
2. 每条线程都有本身的工做内存。工做内存里的变量,在多核处理器下,将大部分储存于处理器高速缓存中。
3. 工做内存会拷贝主存中的变量，而后对变量的操做在本身的工做内存中进行。
4. 线程之间没法相互直接访问，变量传递均须要经过主存完成。

---

 

问题？

如何保证内存计算一致性

1. 缓存一致性

   当一个线程更新了本身工做内存中的数据后，没有写到主内存，其余线程是不知道的。 
  （1）顺序一致性模型:
要求对改变的值当即进行传播, 并确保该值被全部其余线程接受后, 才能继续执行其余指令.
  （2） 释放一致性模型: 
   容许线程将改变的值延迟到锁释放时才进行传播.

---

 

happens-before ordering

1. 1.获取对象监视器的锁(lock)
2. 2. 清空工做内存数据, 从主存复制变量到当前工做内存, 即同步数据 (read and load)
3. 3. 执行代码，改变共享变量值 (use and assign)
4. 4. 将工做内存数据刷回主存 (store and write)
5. 5. 释放对象监视器的锁 (unlock)

happens-before ordering实现

1. final    永不改变
2. volatile 标注被改变的值为原子性
3. JVM优化的锁java.util.concurrent.locks包java.util.concurrent.atmoic包
4. synchronized  堵塞锁

1. 如何选用这些工具呢？前提是保证线程安全性。

---

 

线程安全模式

1. 线程安全性的定义要求不管是多线程中的时序或交替操做，都要保证不破坏业务自己不变约束 。
2. 为了保护状态的一致性，要在单一的原子操做中更新相互关联的状态变量。
3. 设计线程安全的类时，优秀的面向对象技术——封装、不可变性以及明确的不变约束——会给你提供诸多的帮助。 
4. 无状态对象永远是线程安全的

线程安全模式

1. 尽可能不使用synchronized锁，锁是耗费资源和性能的。

1. 首先 编写那些不用任何特别处理的线程安全代码，好比不变性代码。

1. 使用producer-observer模式。

1. 其次：使用Visibility 使资料对全部线程可见。

1. 最后：使用JVM优化的锁。

单值更新

1. 使用Atmoic原子特性API:
2. Atomic{Integer|Long}.compareAndSet().

1. 使用CAS实现机制的API。

1. AtomicReference.compareAndSet()实现不变性对象内部的组合更新。

immutable 不可变模式

1. Immutable是当被构造之后就再也不改变。
2. Immutable 的对象老是线程安全。
3. 特征：
4. 1. 构造之后就不会改变;
5. 2. 全部字段是 final;
6. 3. 它是正常构造。
7. 发布一个Immutable对象是安全的。

Publishing发布公开对象

1. public static Set<Secret> knownSecrets;
2. public void initialize() {
3.     knownSecrets = new HashSet<Secret>();
4. }
5. 因为外界能够访问knownSecrets 而且修改，那么knownSecrets 至关于脱离当前对象的scope生命周期，变成escaped 逃脱了。

安全的发布公开对象模式

1. 发布表明：引用这个对象而且这个对象中状态必须同时为其余人可见的，经过以下方式发布：
2. 1.从一个静态初始期中赋予一个对象引用;
3. public static Holder holder = new Holder(42);
4. 2. 将引用赋予一个 volatile 或者 AtomicReference字段;
5. 3. 将引用赋予一个 final字段，而且构造后不改变（不变性）; or
6. 4.将引用赋予一个 字段被适当的锁守卫。

自然的线程安全

1. Hashtable, synchronizedMap, or Concurrent-Map
2. Vector, CopyOnWriteArrayList, CopyOnWrite-ArraySet, synchronizedList, or synchronizedSet
3. BlockingQueue or a ConcurrentLinkedQueue

---

 

Visibility/NoVisibility模式

1. 线程更新的是本身私有空间变量，须要更新到主内存空间，一个线程修改的结果对于另一个线程是NoVisibility ：
2. class RealTimeClock {
3.    private int clkID;
4.     public int clockID() { return clkID; }
5.     public void setClockID(int id) { clkID = id; } }

1. Thread 1 calls the setClockID method, passing a value of 5.
2. Thread 2 calls the setClockID method, passing a value of 10.
3. Thread 1 calls the clockID method, which returns the value 5.
4. 出现明明修改某个字段值，可是刷新仍是旧值。

多线程访问同一资源

1. 1. 使用synchronized
2. 2. 将clkID 标为volatile

1. 使用synchronized 坏处：排他性锁定，影响性能。

1. 使用JDK5 ReentrantReadWriteLock

---

 

volatile

1. 不是很健壮的锁机制，适合必定条件：
2. 1. 写变量值不依赖它当前值，好比：直接this.xxx = xxx；包括volatile bean
3. 2.这个变量不参与其余变量的不变性范围。
4. 做为标识完成、中断、状态的标记使用
5. 加锁能够保证可见性与原子性（“读-改-写” 原子操做 ）；volatile变量只能保证可见性。
6. 相关文章：http://www.ibm.com/developerworks/java/library/j-jtp06197.html

Volatile缺点

1. @NotThreadSafe
2. public class NumberRange {
3. private int lower, upper;
4. public int getLower() { return lower; }
5. public int getUpper() { return upper; }
6. public void setLower(int value) {
7.     if (value > upper) throw new         IllegalArgumentException(...);
8.    lower = value; }
9. public void setUpper(int value) {
10.    if (value < lower) throw new IllegalArgumentException(...);  
11.         upper = value; } }

Volatile缺点

1. 初始值是(0, 5)
2. 线程A: setLower(4)
3. 线程B: setUpper(3)
4. 结果是 (4, 3) ， 而这一结果根据setLower和setUpper中if逻辑判断是不可能获得的。
5. 这时须要synchronization
6. 或使用final替代Volatile

---

 

使用final替代Volatile

1. 若是须要修改，更换整个对象，值对象定义

原子操做模式

1. 只是将变量做为可见仍是不够，还要对操做这些变量的操做方法保证原子性。
2. 假设有操做A和B，若是从执行A的线程的角度看，当其余线程执行B时，要么B所有执行完成，要么一点都没有执行，这样A和B互为原子操做。一个原子操做是指：该操做对于全部的操做，包括它本身，都知足前面描述的状态。
3. 为了确保线程安全，“检查再运行”操做（如惰性初始化）和读-改-写操做（如自增）必须是原子操做。咱们将“检查再运行”和读-改-写操做的所有执行过程看做是复合操做：为了保证线程安全，操做必须原子地执行。

---

 

锁模式

1. synchronized块：内部锁（intrinsic locks）或监视器锁（monitor locks）
2. 执行线程进入synchronized块以前会自动得到锁。
3. 进入这个内部锁保护的同步块或方法。
4. 内部锁在Java中扮演了互斥锁 。意味着至多只有一个线程能够拥有锁，可能发生死锁，执行synchronized块的线程，不可能看到会有其余线程能同时执行由同一个锁保护的synchronized块。
5. 它彻底禁止多个用户同时使用 ，性能问题

重进入（Reentrancy）

1. 当一个线程请求其余线程已经占有的锁时，请求线程将被阻塞 。线程在试图得到它本身占有的锁时，请求会成功 .
2. public class Widget {
3.     public synchronized void doSomething() {
4.     }}
5. public class LoggingWidget extends Widget {
6.     public synchronized void doSomething() {
7.         System.out.println(toString() + ": calling doSomething");
8.         super.doSomething();
9.     }}

Reentrancy好处

1. 子类覆写了父类synchronized类型的方法，并调用父类中的方法。若是没有可重入的锁，这段看上去很天然的代码就会产生死锁。

---

 

cheap read-write lock

1. public class CheesyCounter {
2. // Employs the cheap read-write lock trick // All mutative operations MUST be done with the 'this' lock held @GuardedBy("this")
3. private volatile int value;
4. public int getValue() { return value; }
5. public synchronized int increment() {
6.          return value++;
7. }
8. }

ReentrantReadWriteLock

1. 适合场景：大量并发读操做，少许甚至一个线程作修改。
2. 优势：克服synchronization跨多个方法没法重入的问题（容易发生死锁），好比 在一个地方lock，而在另一个地方 unlock.
3. public void set(String key, String value) {
4. write.lock();
5. try {dictionary.put(key, value);}
6. finally {write.unlock();}
7. }
8. public String get(String key) {
9. read.lock();
10. try {return dictionary.get(key);}
11. finally {read.unlock();}
12. }

什么时候用

1. 若是须要timed, polled, 或可中断 lock, fair queueing,  non-block-structured locking.就是要ReentrantReadWriteLock

1. 不然使用 synchronized.

---

 

案例：如何实现集合的边读边改

1. 联系人名单集合，发送Email
2. public void sendMessages(Map contactMap) {
3.     sendEmail(contactMap.values());
4. }
5. contactMap是Contact集合，contactMap.values是遍历contactMap中元素Contact对象。
6. 假设：若是在遍历发生Email同时，有新的Contact对象加入到contactMap集合中，这时会抛出并发错误。

设计新的不可变集合

使用新不可变集合类

---

状态和值对象

1. 值对象是DDD中一种模型，不可变性。
2. 状态是表达一段时间内一个逻辑为真的事实，状态是不可变的，由于咱们不能回到过去改变状态。
3. 状态是一种值对象。
4. 经过不变性规避了共享锁的争夺，从而得到了更好的并发性能。
5. 具体案例见jivejdon中的ForumState等

---

 

ThreadLocal

1. ThreadLocal能够维持线程的封闭性，一个请求一个线程，至关于request.setAttribute/getAttribute;
2. ThreadLocal能够为每一个线程保存本身的状态值。
3. ThreadLocal的get/set方法为每一个线程维持一份独立的分离的状态值。Get方法可以返回最新经过set方法保存的状态值
4. 常常被框架使用。如Spring Hibernate

数据库链接放入ThreadLocal

1. private static ThreadLocal<Connection> connectionHolder =
2.     new ThreadLocal<Connection>() {
3.          public Connection initialValue() {
4.                 return DriverManager.getConnection(DB_URL); }
5. } ;
6. public static Connection getConnection() {
7.         return   connectionHolder.get();
8. }