http://www.cnblogs.com/chengxiao/p/6842045.html>
+https://www.cnblogs.com/chengxiao/p/6842045.html>
**JDK1.7 的 ConcurrentHashMap：**  -http://www.cnblogs.com/chengxiao/p/6842045.html>
+https://www.cnblogs.com/chengxiao/p/6842045.html>
**JDK1.8 的 ConcurrentHashMap：** diff --git "a/docs/java/jvm/JVM\345\236\203\345\234\276\345\233\236\346\224\266.md" "b/docs/java/jvm/JVM\345\236\203\345\234\276\345\233\236\346\224\266.md" index d25667a5ab4..13af498732e 100644 --- "a/docs/java/jvm/JVM\345\236\203\345\234\276\345\233\236\346\224\266.md" +++ "b/docs/java/jvm/JVM\345\236\203\345\234\276\345\233\236\346\224\266.md" @@ -131,7 +131,7 @@ public class GCTest { 运行结果 (红色字体描述有误，应该是对应于 JDK1.7 的永久代)： - + 从上图我们可以看出 eden 区内存几乎已经被分配完全（即使程序什么也不做，新生代也会使用 2000 多 k 内存）。假如我们再为 allocation2 分配内存会出现什么情况呢？ @@ -139,7 +139,7 @@ public class GCTest { allocation2 = new byte[900*1024]; ``` - + **简单解释一下为什么会出现这种情况：** 因为给 allocation2 分配内存的时候 eden 区内存几乎已经被分配完了，我们刚刚讲了当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC.GC 期间虚拟机又发现 allocation1 无法存入 Survivor 空间，所以只好通过 **分配担保机制** 把新生代的对象提前转移到老年代中去，老年代上的空间足够存放 allocation1，所以不会出现 Full GC。执行 Minor GC 后，后面分配的对象如果能够存在 eden 区的话，还是会在 eden 区分配内存。可以执行如下代码验证： diff --git "a/docs/java/multi-thread/2020\346\234\200\346\226\260Java\345\271\266\345\217\221\350\277\233\351\230\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" "b/docs/java/multi-thread/2020\346\234\200\346\226\260Java\345\271\266\345\217\221\350\277\233\351\230\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" index 699f434bcab..a817d041397 100644 --- "a/docs/java/multi-thread/2020\346\234\200\346\226\260Java\345\271\266\345\217\221\350\277\233\351\230\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" +++ "b/docs/java/multi-thread/2020\346\234\200\346\226\260Java\345\271\266\345\217\221\350\277\233\351\230\266\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" @@ -12,7 +12,7 @@ - [1.3. 构造方法可以使用 synchronized 关键字修饰么？](#13-构造方法可以使用-synchronized-关键字修饰么) - [1.3. 讲一下 synchronized 关键字的底层原理](#13-讲一下-synchronized-关键字的底层原理) - [1.3.1. synchronized 同步语句块的情况](#131-synchronized-同步语句块的情况) - - [1.3.2. `synchronized` 修饰方法的的情况](#132-synchronized-修饰方法的的情况) + - [1.3.2. synchronized 修饰方法的的情况](#132-synchronized-修饰方法的的情况) - [1.3.3.总结](#133总结) - [1.4. 说说 JDK1.6 之后的 synchronized 关键字底层做了哪些优化，可以详细介绍一下这些优化吗](#14-说说-jdk16-之后的-synchronized-关键字底层做了哪些优化可以详细介绍一下这些优化吗) - [1.5. 谈谈 synchronized 和 ReentrantLock 的区别](#15-谈谈-synchronized-和-reentrantlock-的区别) @@ -86,7 +86,7 @@ ```java synchronized void method() { - //业务代码 + //业务代码 } ``` @@ -94,7 +94,7 @@ synchronized void method() { ```java synchronized static void method() { -//业务代码 + //业务代码 } ``` @@ -102,7 +102,7 @@ synchronized static void method() { ```java synchronized(this) { - //业务代码 + //业务代码 } ``` @@ -167,11 +167,11 @@ public class Singleton { ```java public class SynchronizedDemo { - public void method() { - synchronized (this) { - System.out.println("synchronized 代码块"); - } - } + public void method() { + synchronized (this) { + System.out.println("synchronized 代码块"); + } + } } ``` @@ -194,13 +194,13 @@ public class SynchronizedDemo { 在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。 -#### 1.3.2. `synchronized` 修饰方法的的情况 +#### 1.3.2. synchronized 修饰方法的的情况 ```java public class SynchronizedDemo2 { - public synchronized void method() { - System.out.println("synchronized 方法"); - } + public synchronized void method() { + System.out.println("synchronized 方法"); + } } ``` @@ -277,7 +277,7 @@ JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、  -要解决这个问题，就需要把变量声明为**`volatile`**，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 +要解决这个问题，就需要把变量声明为 **`volatile`** ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。 所以，**`volatile` 关键字 除了防止 JVM 的指令重排 ，还有一个重要的作用就是保证变量的可见性。** @@ -293,7 +293,7 @@ JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、 `synchronized` 关键字和 `volatile` 关键字是两个互补的存在，而不是对立的存在！ -- **`volatile` 关键字**是线程同步的**轻量级实现**，所以**`volatile `性能肯定比` synchronized `关键字要好**。但是**`volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块**。 +- **`volatile` 关键字**是线程同步的**轻量级实现**，所以 **`volatile `性能肯定比` synchronized `关键字要好** 。但是 **`volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块** 。 - **`volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。** - **`volatile`关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。** @@ -379,13 +379,12 @@ Thread Name= 9 formatter = yy-M-d ah:mm 上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA 会提示你转换为 Java8 的格式(IDEA 真的不错！)。因为 ThreadLocal 类在 Java 8 中扩展，使用一个新的方法`withInitial()`，将 Supplier 功能接口作为参数。 ```java - private static final ThreadLocal