先看几张图
泛型？
泛型，本质上是参数化类型，他提供了编译时类型的安全检测机制，注意两点，泛型上限，和下限，一般情况上限object，但是如果是继承或者super关系，
上限为父类或者父接口，还有一点就是泛型擦除机制。
String类的不可变性？
先看下面这段代码：
String s = "abc"; //(1)System.out.println("s = " + s);
s = "123"; //(2)System.out.println("s = " + s);
打印结果为：
s = abc
s = 123
看到这里，你可能对String是不可变对象产生了疑惑，因为从打印结果可以看出，s的值的确改变了。其实不然，因为s只是一个String对象的引用，并不是String对象本身。
当执行(1)处这行代码之后，会先在方法区的运行时常量池创建一个String对象"abc"，然后在Java栈中创建一个String对象的引用s，并让s指向"abc"，如下图所示：
当执行完(2)处这行代码之后，会在方法区的运行时常量池创建一个新的String对象"123"，然后让引用s重新指向这个新的对象，而原来的对象"abc"还在内存中，并没有改变，如下图所示：
public final class String implements java.io.Serializable, Comparable<String>, CharSequence { /** The value is used for character storage. */ private final char value[]; /** Cache the hash code for the string */ private int hash; // Default to 0 /** use serialVersionUID from JDK 1.0.2 for interoperability */ private static final long serialVersionUID = -6849794470754667710L; /** * Class String is special cased within the Serialization Stream Protocol. * * A String instance is written into an ObjectOutputStream according to * <a href="{@docRoot}/../platform/serialization/spec/output.html"> * Object Serialization Specification, Section 6.2, "Stream Elements"</a> */ private static final ObjectStreamField[] serialPersistentFields = new ObjectStreamField[0];
String类使用了final修饰符，表明String类是不可继承的，不可变的，但是他指向的值可以改变。
为什么要这么设计不可变的String
1.运行时常量池的需要
String s1 = "abc";
String s2 = "abc";
执行上述代码时，在运行时常量池中只会创建一个String对象"abc"，这样就节省了内存空间。
2.同步
因为String对象是不可变的，所以是多线程安全的，同一个String实例可以被多个线程共享。这样就不用因为线程安全问题而使用同步。
3允许String对象缓存hashcode
String类常用方法
1、int length();
2、char charAt(值);
3、char toCharArray();
4、 int indexOf("字符")
5、toUpperCase()； toLowerCase()；字符串大小写的转换
6、String[] split("字符")
7、boolean equals(Object anObject)
8、trim();去掉字符串左右空格 replace(char oldChar,char newChar);新字符替换旧字符，也可以达到去空格的效果一种。
9、String substring(int beginIndex,int endIndex) 截取字符串
10、boolean equalsIgnoreCase(String) 忽略大小写的比较两个字符串的值是否一模一样，返回一个布尔值
11、boolean contains(String) 判断一个字符串里面是否包含指定的内容，返回一个布尔值
12、boolean startsWith(String) 测试此字符串是否以指定的前缀开始。返回一个布尔值
13.boolean endsWith(String) 测试此字符串是否以指定的后缀结束。返回一个布尔值
14、上面提到了replace方法，接下继续补充一下 String replaceAll(String,String) 将某个内容全部替换成指定内容， String repalceFirst(String,String) 将第一次出现的某个内容替换成指定的内容
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
并发相关问题：（参看前面的脑图）
并发出现线程不安全的本质什么？
可见性，原子性和有序性，
1.原子性
原子性是指操作是不可分的。其表现在于对于共享变量的某些操作，应该是不可分的，必须连续完成。例如a++，对于共享变量a的操作，实际上会执行三个步骤，1.读取变量a的值 2.a的值+1 3.将值赋予变量a 。 这三个操作中任何一个操作过程中，a的值被人篡改，那么都会出现我们不希望出现的结果。所以我们必须保证这是原子性的。Java中的锁的机制解决了原子性的问题。
2.可见性
可见性是值一个线程对共享变量的修改，对于另一个线程来说是否是可以看到的。
为什么会出现这种问题呢？
我们知道，java线程通信是通过共享内存的方式进行通信的，而我们又知道，为了加快执行的速度，线程一般是不会直接操作内存的，而是操作缓存。
java线程内存模型：
实际上，线程操作的是自己的工作内存，而不会直接操作主内存。如果线程对变量的操作没有刷写会主内存的话，仅仅改变了自己的工作内存的变量的副本，那么对于其他线程来说是不可见的。而如果另一个变量没有读取主内存中的新的值，而是使用旧的值的话，同样的也可以列为不可见。
对于jvm来说，主内存是所有线程共享的java堆，而工作内存中的共享变量的副本是从主内存拷贝过去的，是线程私有的局部变量，位于java栈中。
那么我们怎么知道什么时候工作内存的变量会刷写到主内存当中呢？
这就涉及到java的happens-before关系了。
在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。
简单来说，只要满足了happens-before关系，那么他们就是可见的。
显然，一般只需要使用volatile关键字，或者使用锁的机制，就能实现内存的可见性了。
3 .有序性
有序性是指程序在执行的时候，程序的代码执行顺序和语句的顺序是一致的。
为什么会出现不一致的情况呢？
这是由于重排序的缘故。
在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
举个例子：
线程A:
context = loadContext();
inited = true;
线程B:
while(!inited ){
sleep
}
doSomethingwithconfig(context);
如果线程A发生了重排序：
inited = true;
context = loadContext();
那么线程B就会拿到一个未初始化的content去配置，从而引起错误。
因为这个重排序对于线程A来说是不会影响线程A的正确性的，而如果loadContext()方法被阻塞了，为了增加Cpu的利用率，这个重排序是可能的。
如果要防止重排序，需要使用volatile关键字，volatile关键字可以保证变量的操作是不会被重排序的。
线程相关的基本方法有 wait，notify，notifyAll，sleep，join，yield 等。
1. 线程等待（wait）
调用该方法的线程进入 WAITING 状态，只有等待另外线程的通知或被中断才会返回，需要注意的是调用 wait()方法后，会释放对象的锁。因此，wait 方法一般用在同步方法或同步代码块中。
2. 线程睡眠（sleep）
sleep 导致当前线程休眠，与 wait 方法不同的是 sleep 不会释放当前占有的锁,sleep(long)会导致线程进入 TIMED-WATING 状态，而 wait()方法会导致当前线程进入 WATING 状态
3. 线程让步（yield）
yield 会使当前线程让出 CPU 执行时间片，与其他线程一起重新竞争 CPU 时间片。一般情况下，优先级高的线程有更大的可能性成功竞争得到 CPU 时间片，但这又不是绝对的，有的操作系统对线程优先级并不敏感。
4. 线程中断（interrupt）
中断一个线程，其本意是给这个线程一个通知信号，会影响这个线程内部的一个中断标识位。这个线程本身并不会因此而改变状态(如阻塞，终止等)。
（1）. 调用 interrupt()方法并不会中断一个正在运行的线程。也就是说处于 Running 状态的线程并不会因为被中断而被终止，仅仅改变了内部维护的中断标识位而已。
（2）. 若调用 sleep()而使线程处于 TIMED-WATING 状态，这时调用 interrupt()方法，会抛出InterruptedException,从而使线程提前结束 TIMED-WATING 状态。
（3）.许多声明抛出 InterruptedException 的方法(如 Thread.sleep(long mills 方法))，抛出异常前，都会清除中断标识位，所以抛出异常后，调用 isInterrupted()方法将会返回 false。
（4）. 中断状态是线程固有的一个标识位，可以通过此标识位安全的终止线程。比如,你想终止一个线程 thread 的时候，可以调用 thread.interrupt()方法，在线程的 run 方法内部可以根据thread.isInterrupted()的值来优雅的终止线程。
5. Join 方法：等待其他线程终止，在当前线程中调用一个线程的 join() 方法，则当前线程转为阻塞状态，回到另一个线程结束，当前线程再由阻塞状态变为就绪状态，等待 cpu 的宠幸。
6. 为什么要用 join()方法？
很多情况下，主线程生成并启动了子线程，需要用到子线程返回的结果，也就是需要主线程需要在子线程结束后再结束，这时候就要用到 join() 方法。
7. 线程唤醒（notify）
Object 类中的 notify() 方法，唤醒在此对象监视器上等待的单个线程，如果所有线程都在此对象上等待，则会选择唤醒其中一个线程，选择是任意的，并在对实现做出决定时发生，线程通过调用其中一个 wait() 方法，在对象的监视器上等待，直到当前的线程放弃此对象上的锁定，才能继续执行被唤醒的线程，被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争。类似的方法还有 notifyAll() ，唤醒再次监视器上等待的所有线程。
synchronized详解？
定位和使用：
是一种 对象锁（锁的是对象而非引用变量），作用粒度是对象 ，可以用来实现对 临界资源的同步互斥访问 ，是 可重入 的。其可重入最大的作用是避免死锁
synchronized只能用于代码块或者方法，不可以用于类。如果要使用类锁，可以将类对象设为xxx.class或者修饰静态代码块。
一个对象有一把锁（class也是对象），且同时只能被一个线程获得。其他未获得锁的线程只能等待
每个实例对象都有一把锁(this)，且不同实例对象的锁互不影响，除非：锁对象是*.class以及synchronized修饰的是static方法的时候，所有对象公用同一把锁（也就是类锁）
synchroniezd修饰的方法，正常执行结束和抛出异常都会释放锁。
Synchronized的用法可以分为两种：对象锁和类锁
对象锁，有两种形式：代码块&&方法锁
代码块形式下，可以由用户自己指定 作为锁的对象 也可以 使用this。
方法锁，即使用synchronized关键字修饰方法名，该情况下默认使用this作为锁对象
类锁：synchronize修饰静态的方法或指定锁对象为Class对象
synchronized 底层实现：synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令
java中每个对象都关联着一个监视器锁（monitor），每一个对象在同一时间只与一个monitor(锁)相关联。
和monitor有关的命令有两个
monitorenter:用于当前线程获取monitor
Monitorexit:用于当前线程释放monitor
而在这个enter和exit的过程中，我理解就是计数器+1-1的操作。
synchronized性质的原理 ：
1
可重入原理：加锁次数计数器(每个线程单独计数器，互不影响）
2
保证可见性的原理：内存模型和happens-before规则（
happens-before作用于监视器
synchronized局限性+ Lock锁机制的引入：
synchronized局限性
第一，使用synchronized，其他线程只能等待直到持有锁的线程执行完释放锁（synchronized释放锁有且仅有两种情况）
如果一个代码块被synchronized修饰了，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的线程释放锁，但是获取锁的线程释放锁只会有两种情况：
释放synchronized同步锁的第一种情况：获取锁的线程执行完了该代码块，然后线程释放对锁的占有；
释放synchronized同步锁的第二种情况：线程执行发生异常，此时JVM会让线程自动释放锁（tip：这也是synchronized的一个好处，不会造成死锁）。
因此，可以看到，其他线程只能等待直到持有锁的线程执行完释放锁。
第二，使用synchronized，非公平锁使一些线程处于饥饿状态
synchronized实现的锁，只能是非公平的强制锁，对于一些线程，可能长久无法抢占到锁，导致处于饥饿状态，对于某些特定的业务场景，必须要使用公平锁，这时，synchronized同步锁无法满足要求。
第三，使用synchronized，多个线程都只是进行读操作时，线程之间也会发生冲突
当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。
但是采用synchronized关键字来实现同步的话，就会导致一个问题：即使多个线程都只是进行读操作，当一个线程在进行读操作时，其他线程也只能等待无法进行读操作。
最后，Lock对于三个问题的解决/Lock相对于synchronized的三个优点（有限等待、公平锁、读写锁）
有限等待、可中断、有返回值
（1）有限等待：需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），这个是synchronized无法办到，Lock可以办到，由tryLock(带时间参数)实现；
（2）可中断：使用synchronized时，等待的线程会一直阻塞，一直等待下去，不能够响应中断，而Lock锁机制可以让等待锁的线程响应中断，由lockInterruptibly()实现；
（3）有返回值：需要一种机制可以知道线程有没有成功获得到锁，这个是synchronized无法办到，Lock可以办到，由tryLock()方式实现；
公平锁：synchronized中的锁是非公平锁，ReentrantLock默认情况下也是非公平锁，但可以通过构造方法ReentrantLock(true)来要求使用公平锁（底层由Condition的等待队列实现）。
读写锁，提高多个线程读操作并发效率：需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，这个是synchronized无法办到，Lock可以办到。
整体理解，Lock接口的类结构示意图
锁优化？
简单来说在JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的
不过在jdk1.6中对锁的实现引入了大量的优化，如锁粗化(Lock Coarsening)、锁消除(Lock Elimination)、轻量级锁(Lightweight Locking)、偏向锁(Biased Locking)、适应性自旋(Adaptive Spinning)等技术来减少锁操作的开销。
锁粗化(Lock Coarsening)：也就是减少不必要的紧连在一起的unlock，lock操作，将多个连续的锁扩展成一个范围更大的锁。
锁消除(Lock Elimination)：通过运行时JIT编译器的逃逸分析来消除一些没有在当前同步块以外被其他线程共享的数据的锁保护，通过逃逸分析也可以在线程本地Stack上进行对象空间的分配(同时还可以减少Heap上的垃圾收集开销)。
轻量级锁(Lightweight Locking)：这种锁实现的背后基于这样一种假设，即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态(即单线程执行环境)，在无锁竞争的情况下完全可以避免调用操作系统层面的重量级互斥锁，取而代之的是在monitorenter和monitorexit中只需要依靠一条CAS原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下，执行CAS指令失败的线程将调用操作系统互斥锁进入到阻塞状态，当锁被释放的时候被唤醒(具体处理步骤下面详细讨论)。
偏向锁(Biased Locking)：是为了在无锁竞争的情况下避免在锁获取过程中执行不必要的CAS原子指令，因为CAS原子指令虽然相对于重量级锁来说开销比较小但还是存在非常可观的本地延迟。
适应性自旋(Adaptive Spinning)：当线程在获取轻量级锁的过程中执行CAS操作失败时，在进入与monitor相关联的操作系统重量级锁(mutex semaphore)前会进入忙等待(Spinning)然后再次尝试，当尝试一定的次数后如果仍然没有成功则调用与该monitor关联的semaphore(即互斥锁)进入到阻塞状态。
锁膨胀方向： 无锁 → 偏向锁 → 轻量级锁 → 重量级锁 (此过程是不可逆的)
原文：https://www.cnblogs.com/yangj-Blog/p/14586949.html