最后
给大家送一个小福利
附高清脑图，高清知识点讲解教程，以及一些面试真题及答案解析。送给需要的提升技术、准备面试跳槽、自身职业规划迷茫的朋友们。
ReentrantLock是Lock的实现类，是一个互斥的同步锁.从功能角度，ReentrantL ock比Synchronized 的同步操作更精细(因为可以像普通对象一样使用)，甚至实现Synchronized没有的高级功能，如:
●等待可中断:当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，对处理执行时间非常长的同步块很有用。
●带超时的获取锁尝试:在指定的时间范围内获取锁，如果时间到了仍然无法获取则返回。
●可以判断是否有线程在排队等待获取锁。
●可以响应中断请求:与Synchronized不同，当获取到锁的线程被中断时，能够响应中断，中断异常将会被抛出，同时锁会被释放。
●可以实现公平锁。
ReentrantL ock内部自定义了同步器Sync(Sync既实现了AQS，而AOS提供了一种互斥锁持有的方式)，其实就是加锁的时候通过CAS算法，将线程对象放到一个双向链表中，每次获取锁的时候，看下当前维护的那个线程ID和当前请求的线程ID 是否一样，一样就可重入了。
5、除了ReetrantLock,你还接触过JUC中的哪些并发工具?
通常所说的并发包(JUC)也就是java.util.concurrent及其子包，集中了Java并发的各种基础工具类，具体主要包括几个方面:
●提供了CountDownL atch、CyliBarrier. Semaphore等， 比
Synchronized更加高级，可以实现更加丰富多线程操作的同步结构。
●提供了ConcurrentHashMap、有序的ConcunrrentSkipListMap,或者通过类似快照机制实现线程安全的动态数组CopyOnWriteArrayList 等各种线程安全的容器。
●提供了ArrayBlockingQueue、SynchorousQueue 或针对特定场景的PriorityBlockingQueue等，各种并发队列实现。
●强大的Executor 框架，可以创建各种不同类型的线程池，调度任务运行等。
6、请谈谈ReadWriteLock和StampedLock.
虽然Reentrantl ock和Synchronized简单实用，但是行为上有一定局限性，要么不占，要么独占。实际应用场景中，有时候不需要大量竞争的写操作，而是以并发读取为主，为了进一步优化并发操作的粒度, Java 提供了读写锁。读写锁基于的原理是多个读操作不需要互斥，如果读锁试图锁定时，写锁是被某个线程持有，读锁将无法获得，而只好等待对方操作结束，这样就可以自动保证不会读取到有争议的数据。
ReadWriteLock代表了一对锁，下面是一个基于读写锁实现的数据结构,当数据量较大，并发读多、并发写少的时候，能够比纯同步版本凸显出优势:
读写锁看起来比Synchronized的粒度似乎细一些，但在实际应用中，其表现也并不尽如入意，主要还是因为相对比较大的开销。所以，JDK 在后期引入了StampedL ock,在提供类似读写锁的同时，还支持优化读模式。
优化读基于假设,大多数情况下读操作并不会和写操作冲突,其逻辑是先试着修改，然后通过validate方法确认是否进入了写模式，如果没有进入，就成功避免了开销;如果进入，则尝试获取读锁。
7、CyclicBarrier 和CountDownLatch看起来很相似，请对比下呢?
它们的行为有一定相似度，区别主要在于:
●CountDownLatch是不可以重置的，所以无法重用，CyclicBarrier 没有这种限制，可以重用。
●CountDownLatch的基本操作组合是countDown/await，调用await的线程阻塞等待countDown足够的次数，不管你是在一个线程还是多个线程里countDown,只要次数足够即可。CyclicBarrier 的基本操作组合就是await，当所有的伙伴都调用了await,才会继续进行任务，并自动进行重置。
CountDownL atch目的是让一个线程等待其他N个线程达到某个条件后，自己再去做某个事(通过CydlicBarrier的第二个构造方法publicCylicBarrier(int parties, Runnable barrierAction),在新线程里做事可以达到同样的效果)。而CyllicBarrier的目的是让N多线程互相等待直到所有的都达到某个状态，然后这N个线程再继续执行各自后续(通过CountDownL atch在某些场合也能完成类似的效果)。
●在Java中，所谓的线程池中的“线程”，其实是被抽象为了一个静态内部类Worker,它基于AQS实现，存放在线程池的HashSet workers成员变量中;
●而需要执行的任务则存放在成员变量workQueue(BlockingQueueworkQueue)中。
这样，整个线程池实现的基本思想就是:从workQueue中不断取出需要执行的任务，放在Workers中进行处理。
Java中的线程池的创建其实非常灵活，我们可以通过配置不同的参数,创建出行为不同的线程池，这几个参数包括:
●corePoolSize:线程池的核心线程数。
●maximumPoolSize:线程池允许的最大线程数。
●keepAliveTime:超过核心线程数时闲置线程的存活时间。
●workQueue:任务执行前保存任务的队列，保存由execute方法提交的Runnable任务。
10、什么是Java的内存模型，Java中各个线程是怎么彼此看到对方的变量的?
Java的内存模型定义了程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出这样的底层细节。此处的变量包括实例字段、静态字段和构成数组对象的元素，但是不包括局部变量和方法参数,因为这些是线程私有的，不会被共享，所以不存在竞争问题。
Java中各个线程是怎么彼此看到对方的变量的呢?Java中定义了主内存与工作内存的概念:
所有的变量都存储在主内存，每条线程还有自己的工作内存，保存了被该线程使用到的变量的主内存副本拷贝。
线程对变量的所有操作(读取、赋值)都必须在工作内存中进行，不能直接读写主内存的变量。不同的线程之间也无法直接访问对方工作内存的变量,线程间变量值的传递需要通过主内存。
11、既然volatile能够保证线程间的变量可见性，是不是就意味着基于volatile变量的运算就是并发安全的?
显然不是的。基于volatile变量的运算在并发下不一定是安全的。volatile ;变量在各个线程的工作内存，不存在-致性问题(各个线程的工作内存中volatile变量,每次使用前都要刷新到主内存)。但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。
12、请对比下volatile对比Synchronized的异同。
Synchronized既能保证可见性，又能保证原子性，而volaile只能保证可见性，无法保证原子性
ThreadL ocal和Synchonized都用于解决多线程并发访问，防止任务在共享资源上产生冲突。但是ThreadL ocal与Synchronized有本质的区别。
Synchronized用于实现同步机制，是利用锁的机制使变量或代码块在某一时该只能被一个线程访问，是一种“以时间换空间”的方式。而ThreadLocal为每一个线程都提供 了变量的副本，使得每个线程在某一时间访问到的并不是同一个对象，根除了对变量的共享，是一种“以空间换时间”的方式。
最后如何让自己一步步成为技术专家
说句实话，如果一个打工人不想提升自己，那便没有工作的意义，毕竟大家也没有到养老的年龄。
当你的技术在一步步贴近阿里p7水平的时候，毫无疑问你的薪资肯定会涨，同时你能学到更多更深的技术，交结到更厉害的大牛。
推荐一份Java架构之路必备的学习笔记，内容相当全面！！！
成年人的世界没有容易二字，前段时间刷抖音看到一个程序员连着加班两星期到半夜2点的视频。在这个行业若想要拿高薪除了提高硬实力别无他法。
你知道吗？现在有的应届生实习薪资都已经赶超开发5年的程序员了，实习薪资26K，30K，你没有紧迫感吗？做了这么多年还不如一个应届生，真的非常尴尬！
进了这个行业就不要把没时间学习当借口，这个行业就是要不断学习，不然就只能被裁员。所以，抓紧时间投资自己，多学点技术，眼前困难，往后轻松！
【关注】+【转发】+【点赞】支持我！创作不易！
】+【转发】+【点赞】支持我！创作不易！**
498
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
