java">void 取款(){int oldBalance =balance
if(!CAS(balance,oldBalance,oldBalance-500)){}}在这个线程中如果变成了这样
java">void 取款(){int oldBalance =balancevoid 取款(){int oldBalance =balance
if(!CAS(balance,oldBalance,oldBalance-500)){}有人转账发生了500->1000。}
if(!CAS(balance,oldBalance,oldBalance-500)){}}这两个东西不相等，就会产生bug，上述的过程就属于ABA问题的典型bug场景是非常高极端的情况
如何避免ABA问题呢？？
核心思路是，使用账户余额判定，本身就不太科学．账户余额本身就属于"能加也能减”，就容易出现ABA问题，
引入"版本号”，约定版本号，只能加，不能减~～每次操作一次余额，版本号都要+1通过CAS判定版本号，就可以进一步的来完成上述的操作～~
一个版本号走一步
JUC中的常见类
Callable接口
java">public class Test {private static int sum=0;public static void main(String[] args) throws InterruptedException {Thread t=new Thread(new Runnable() {@Overridepublic void run() {int result=0;for (int i = 0; i <=1000 ; i++) {result+=i;}sum=result;}});t.start();t.join();System.out.println(sum);}
}
java"> Thread t=new Thread(callable)Callable不能直接填写到Thread构造方法中
java">import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;public class Test1 {public static void main(String[] args) throws InterruptedException, ExecutionException {Callable<Integer> callable=new Callable<Integer>() {@Overridepublic Integer call() throws Exception {int result=0;for (int i = 0; i <10000 ; i++) {result+=i;}return result;}};//这是FutureTask的包装类FutureTask<Integer>futureTask=new FutureTask<>(callable);Thread thread=new Thread(futureTask);thread.start();thread.join();System.out.println(futureTask.get());}
}
FutureTask就像中间上来赚取差价。靠他们中间。
线程创建的方式：
1）继承Thread
2)使用Runnable
3）使用lambda
4）使用线程池/ThreadFactory
5）使用Callable
ReentrantLock
java">import java.util.concurrent.locks.ReentrantLock;public class Test2 {public static void main(String[] args) {ReentrantLock lock = new ReentrantLock();try {lock.lock();}finally {lock.unlock();}}
}
1.ReentrantLock提供了公平锁的实现synchronized只是非公平锁。
java"> ReentrantLock lock = new ReentrantLock(true);2.ReentrantLock提供tryLock操作.
给加锁提供了更多的课操作空间尝试加锁，如果锁已经被获取到了，直接返回失败，而不会继续等待。
Synchronized都是遇到锁竞争，就阻塞等待.（死等）
tryLock除了直接返回这种形态之外还有一个版本，可以指定等待超时时间
3.synchronized是搭配waitnotify等待通知机制
ReentrantLock是搭配Condition类完成等待通知Condition要比waitnotify更强一点（多个线程wait，notify是唤醒随机的一个.Condition指定线程唤醒）
信号量Semaphore
信号量就是一个计数器，描述了可用资源的个数
围绕信号量有两个基本操作
1.P操作.计数器-1.申请资源
2.V操作.计数器+1.释放资源
通过Semaphore完成
java">import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;public class Test2 {private final static Semaphore semaphore = new Semaphore(1);public static void main(String[] args){ExecutorService pools = Executors.newCachedThreadPool();for (int i=0 ; i < 10;i++){final int index = i;Runnable run = new Runnable() {@Overridepublic void run() {try {semaphore.acquire();} catch (InterruptedException e) {e.printStackTrace();} finally {//使用完成释放锁semaphore.release();System.out.println("锁释放");}}};pools.execute(run);}pools.shutdown();}}
CountDownLatch
多线程下载.
把一个大的文件，拆分成多个部分．比如20个部分
每个线程都独立和人家服务器建立连接，分20个连接进行下载
等所有线程下载完毕之后，再结果进行合并.
CountDownLatch
java">import java.util.concurrent.CountDownLatch;public class Test3 {public static void main(String[] args) throws InterruptedException {CountDownLatch latch = new CountDownLatch(10);latch.countDown();latch.await();//await会阻塞等待，一直到countDown调用的次数，和构造方法指定的次数一致的时候，，await才会返回}
}
Vector自带了synchronized加锁不能保证线程一定安全
Stack继承自Vector，也自带了synchronized不加锁也不能确定线程一定不安全
Hashtable也是自带synchronized一定要具体代码具体分析～~
java"> Vector<String>vector=new Vector<>();void func(){if(vector.size()>0){System.out.println(vector.get(0));}}比如t1纟线程执行func到if之后t2线程把巴vector清空了回到t1继续执行，get(0)就出问题了，
java"> Collections.synchronizedList(new ArrayList)给ArrayList这些集合类，套一层壳
壳上是给关键方法都加了synchronized就可以使ArrayList达到类似于Vector效果。
CopyOnWriteArrayList
写时拷贝
修改的同时，很多线程在读呢如果直接修改，不加任何处理意味着有的线程可能会读到200，3这种“中间情况。
写完之后，用新的数组的引用，代替旧的数组的引用（3|用赋值操作，是原子的）上述过程，没有任何加锁和阻塞等待，也能确保读线程不会读出“错误的数据旧的空间就可以释放了。
多线程使用队列
直接使用BlockingQueue即可.
HashMap是线程不安全的Hashtable是带锁的，是否就线程更安全呢？？但是这个并不推荐使用
Hashtable加锁就是简单粗暴给每个方法加了synchronized.就相当于是针对this加锁.只要针对Hashtable上的元素进行操作，就都会涉及到锁冲突，
ConcurrentHashMap做出了优化
1.使用“锁桶”的方式，来代替“一把全局锁”，有效降低锁冲突的概率
另一方面，看起来锁对象多了，实际上也不会产生更多的额外开销Java中每个对象都可以作为锁对象就只需要把synchronized加到链表
一个hash表，上面的hash桶的个数是非常多～~大部分的操作，都没有锁冲突了，(synchronized,如果不产生锁冲突，就是个偏向锁)
2.像hash表的size，即使你插入的元素是不同的链表上的元素，也会涉及到多线程修改同一个变量
3.针对扩容操作做了特殊优化
如果发现负载因子太大了，就需要扩容扩容是一个比较重量比较低效的操作。
化整为零.ConcurrentHashMap会在扩容的时候，搞两份空间.
一份是之前扩容之前的空间一份是扩容之后的空间接下来每次进行hash表的基本操作，都会把一部分数据从I旧空间搬运到新空间
搬的过程中：1.插入=>插入到新的上面2.删除=>新的日的都要删除3.查找=>新的日的都要查找
java8之前，ConcurrentHashMap基于分段锁的方式实现的，
引l入若干个锁对象，每个锁对象管理若干个hash桶相比于Hashtable是进化，但是不如现在直接锁桶代码写起来更复杂
