本文目录
- JAVA架构之线程池是怎样工作的
- 如何更好的使用JAVA线程池
- 菜鸡求问，c++里的epoll和java里的线程池到底怎么理解，优劣如何
- java多线程有哪些实际的应用场景
- 线程池处理流程是什么
- 面试时，如何在众多Java工程师中脱颖而出
- java线程池怎么配置最好比如阻塞队列的选择
JAVA架构之线程池是怎样工作的
谢谢邀请！下面介绍一下线程池是怎样工作的？
ThreadPoolExecutor 的类关系如下：
Executor是一个接口，它是Executor框架的基础，它将任务的提交与任务的执行分离开来。
ExecutorService接口继承了Executor，在其上做了一些shutdown()、submit()的扩展，可以说是真正的线程池接口；
AbstractExecutorService抽象类实现了ExecutorService接口中的大部分方法；
threadPoolExecutor是线程池的核心实现类，用来执行被提交的任务。
ScheduledExecutorService接口继承了ExecutorService接口，提供了带“周期执行“功能ExecutorService；
ScheduledThreadPoolExecutor是一个实现类，可以在给定的延迟后运行命令，或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活，功能更强大。
定义线程池
线程池的创建各个参数含义 及流程 如下：
1、corePoolSize
① 线程池中的核心线程数，当提交一个任务时，线程池创建一个新线程执行任务，直到当前线程数等于corePoolSize；
② 如果当前线程数为corePoolSize，继续提交的任务被保存到阻塞队列中，等待被执行；
③ 如果执行了线程池的prestartAllCoreThreads()方法，线程池会提前创建并启动所有核心线程。
2、maximumPoolSize
线程池中允许的最大线程数。如果当前阻塞队列满了，且继续提交任务，
则创建新的线程执行任务，前提是当前线程数小于maximumPoolSize
3、keepAliveTime
线程空闲的存活时间，即当线程没有任务执行时，继续存活的时间。
默认情况下，该参数只在线程数大于 corePoolSize时才有用。
4、TimeUnit
keepAliveTime 的时间单位。
5、WorkQueue
用于保存等待执行的任务的阻塞队列，一般来说，我们应该尽量使用有界队列，因为使用无界队列作为工作队列会对线程池做如下影响。
① 当线程池中的线程数达到corePoolSize后，新任务将在无界队列中等待，因此线程池中的线程数不会超过corePoolSize。
② 由于1，使用无界队列时maximumPoolSize将是一个无效参数。
③ 由于1和2，使用无界队列时keepAliveTime将是一个无效参数。
④ 更重要的，使用无界queue可能会耗尽系统资源，有界队列则有助于防止资源耗尽，同时即使使用有界队列，也要尽量控制队列的大小在一个合适的范围。
所以我们一般会使用，ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue、PriorityBlockingQueue。
6、threadfactory
创建线程的工厂，通过自定义的线程工厂可以给每个新建的线程设置一个具有识别度的线程名，
当然还可以更加自由的对线程做更多的设置，比如设置所有的线程为守护线程。
Executors 静态工厂里默认的threadfactory，线程的命令 规则时“pool-数字-thread-数字“
7、RejectedExecutionHandler 拒绝策略
线程池的饱和策略，当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了4种策略：
① AbortPolicy : 直接抛出异常，默认策略
② CallerRunsPolicy: 用调用者所在的线程来执行任务
③ DiscardOldestPolicy : 丢弃阻塞队列中靠最前的任务，并执行当前任务
④ Discardpolicy : 直接丢弃任务
当然也可以根据应用场景实现RejectedExecutionHandler接口，自定义饱和策略，如记录日志或持久化存储不能处理的任务。
线程池的工作机制
① 如果当前运行的线程 少于corePoolSize,则创建新线程来执行任务
② 如果运行的线程等于或多于corePoolSize，则将任务加入BlockingQueue
③ 如果无法将任务加入BlockingQueue（队列已满），则创建新的线程来处理任务。
④ 如果创建新线程将使当前运行的线程超出 maximumPoolSize,任务将被拒绝，
并调用RejectedExecutionHandler.rejectedExecution()方法。
如何更好的使用JAVA线程池
线程池是为了解决线程创建资源消耗问题而出现的。所以要更好的使用线程池就要分别从线程池大小参数的设置、工作线程的创建、空闲线程的回收、阻塞队列的使用、任务拒绝策略、线程池Hook等方面来了解线程池的使用，其中涉及到一些细节包括不同参数、不同队列、不同拒绝策略的选择、产生的影响和行为、为更好的使用线程池奠定知识基础。
ExecutorService基于池化的线程来执行用户提交的任务，通常可以简单的通过Executors提供的工厂方法来创建ThreadPoolExecutor实例。
线程池解决的两个问题：
- 线程池通过减少每次做任务的时候产生的性能消耗来优化执行大量的异步任务的时候的系统性能。
- 线程池还提供了限制和管理批量任务被执行的时候消耗的资源、线程的方法。另外ThreadPoolExecutor还提供了简单的统计功能，比如当前有多少任务被执行完了。
快速开始
为了使得线程池适合大量不同的应用上下文环境，ThreadPoolExecutor提供了很多可以配置的参数和可被用来扩展的钩子。然而，用户还可以通过使用Executors提供的一些工厂方法来快速创建ThreadPoolExecutor实例。比如：
- 使用Executors#newCachedThreadPool可以快速创建一个拥有自动回收线程功能且没有限制的线程池。
- 使用Executors#newFixedThreadPool可以用来创建一个固定线程大小的线程池。
- 使用Executors#newSingleThreadExecutor可以用来创建一个单线程的执行器。
如果上面的方法创建的实例不能满足我们的需求，我们可以自己通过参数来配置，实例化一个实例。
关于线程数大小参数设置
ThreadPoolExecutor会根据corePoolSize和maximumPoolSize来动态调整线程池的大小:poolSize。
当任务通过executor提交给线程池的时候，我们需要知道下面几个点：
- 如果这个时候当前池子中的工作线程数小于corePoolSize，则新创建一个新的工作线程来执行这个任务，不管工作线程集合中有没有线程是处于空闲状态。
- 如果池子中有比corePoolSize大的但是比maximumPoolSize小的工作线程，任务会首先被尝试着放入队列，这里有两种情况需要单独说一下：
- 如果任务被成功的放入队列，则看看是否需要开启新的线程来执行任务，只有当当前工作线程数为0的时候才会创建新的线程，因为之前的线程有可能因为都处于空闲状态或因为工作结束而被移除。
- 如果放入队列失败，则才会去创建新的工作线程。
- 如果corePoolSize和maximumPoolSize相同，则线程池的大小是固定的。
- 通过将maximumPoolSize设置为无限大，我们可以得到一个无上限的线程池。
- 除了通过构造参数设置这几个线程池参数之外我们还可以在运行时设置。
核心线程WarmUp
默认情况下，核心工作线程值在初始的时候被创建，当新任务来到的时候被启动，但是我们可以通过重写prestartCoreThread或prestartCoreThreads方法来改变这种行为。通常场景我们可以在应用启动的时候来WarmUp核心线程，从而达到任务过来能够立马执行的结果，使得初始任务处理的时间得到一定优化。
定制工作线程的创建
新的线程是通过ThreadFactory来创建的，如果没有指定，默认的Executors#defaultThreadFactory将被使用，这个时候创建的线程将都属于同一个线程组，拥有同样的优先级和daemon状态。扩展配置ThreadFactory，我们可以配置线程的名字、线程组合daemon状态。如果调用ThreadFactory#createThread的时候失败，将返回null，executor将不会执行任何任务。
空闲线程回收
如果当前池子中的工作线程数大于corePoolSize，如果超过这个数字的线程处于空闲的时间大于keepAliveTime，则这些线程将会被终止，这是一种减少不必要资源消耗的策略。这个参数可以在运行时被改变，我们同样可以将这种策略应用给核心线程，我们可以通过调用allowCoreThreadTimeout来实现。
选择合适的阻塞队列
所有的阻塞队列都可以被用来存放任务，但是使用不同的队列针对corePoolSize会表现不同的行为：
1、当池中工作线程数小于corePoolSize的时候，每次来任务的时候都会创建一个新的工作线程。
2、当池中工作线程数大于等于corePoolSize的时候，每次任务来的时候都会首先尝试将线程放入队列，而不是直接去创建线程。
3、如果放入队列失败，且当先池中线程数小于maximumPoolSize的时候，则会创建一个工作线程。
下面主要是不同队列策略表现:
1、直接递交：一种比较好的默认选择是使用SynchronousQueue，这种策略会将提交的任务直接传送给工作线程，而不持有。如果当前没有工作线程来处理，即任务放入队列失败，则根据线程池的实现，会引发新的工作线程创建，因此新提交的任务会被处理。这种策略在当提交的一批任务之间有依赖关系的时候避免了锁竞争消耗。值得一提的是，这种策略最好是配合unbounded线程数来使用，从而避免任务被拒绝。同时我们必须要考虑到一种场景，当任务到来的速度大于任务处理的速度，将会引起无限制的线程数不断的增加。
2、无界队列：使用无界队列如LinkedBlockingQueue没有指定最大容量的时候，将会引起当核心线程都在忙的时候，新的任务被放在队列上，因此，永远不会有大于corePoolSize的线程被创建，因此maximumPoolSize参数将失效。这种策略比较适合所有的任务都不相互依赖，独立执行。举个例子，如网页服务器中，每个线程独立处理请求。但是当任务处理速度小于任务进入速度的时候会引起队列的无限膨胀。
3、有界队列：有界队列如ArrayBlockingQueue帮助限制资源的消耗，但是不容易控制。队列长度和maximumPoolSize这两个值会相互影响，使用大的队列和小maximumPoolSize会减少CPU的使用、操作系统资源、上下文切换的消耗，但是会降低吞吐量，如果任务被频繁的阻塞如IO线程，系统其实可以调度更多的线程。使用小的队列通常需要大maximumPoolSize，从而使得CPU更忙一些，但是又会增加降低吞吐量的线程调度的消耗。总结一下是IO密集型可以考虑多些线程来平衡CPU的使用，CPU密集型可以考虑少些线程减少线程调度的消耗。
选择适合的拒绝策略
当新的任务到来的而线程池被关闭的时候，或线程数和队列已经达到上限的时候，我们需要去做一个决定，怎么拒绝这些任务。下面介绍一下常用的策略：
1、ThreadPoolExecutor#AbortPolicy：这个策略直接抛出RejectedExecutionException异常。
2、ThreadPoolExecutor#CallerRunsPolicy：这个策略将会使用Caller线程来执行这个任务，这是一种feedback策略，可以降低任务提交的速度。
3、ThreadPoolExecutor#DiscardPolicy：这个策略将会直接丢弃任务。
4、ThreadPoolExecutor#DiscardOldestPolicy：这个策略将会把任务队列头部的任务丢弃，然后重新尝试执行，如果还是失败则继续实施策略。
除了上面的几种策略，我们也可以通过实现RejectedExecutionHandler来实现自己的策略。
利用Hook嵌入你的行为
ThreadPoolExecutor提供了protected类型可以被覆盖的钩子方法，允许用户在任务执行之前会执行之后做一些事情。我们可以通过它来实现比如初始化ThreadLocal、收集统计信息、如记录日志等操作。这类Hook如beforeExecute和afterExecute。另外还有一个Hook可以用来在任务被执行完的时候让用户插入逻辑，如rerminated。
如果hook方法执行失败，则内部的工作线程的执行将会失败或被中断。
可访问的队列
getQueue方法可以用来访问queue队列以进行一些统计或者debug工作，我们不建议用作其他用途。同时remove方法和purge方法可以用来将任务从队列中移除。
关闭线程池
当线程池不在被引用并且工作线程数为0的时候，线程池将被终止。我们也可以调用shutdown来手动终止线程池。如果我们忘记调用shutdown，为了让线程资源被释放，我们还可以使用keepAliveTime和allowCoreThreadTimeOut来达到目的。
我们在写程序时要注意自己的应用场景，根据场景使用合适的策略和参数才是正确的打开方式，有问题可以私信我。欢迎交流！
菜鸡求问，c++里的epoll和java里的线程池到底怎么理解，优劣如何
服务器并发模型通常可分为单线程和多线程模型，这里的线程通常是指“I/O线程”，即负责I/O操作，协调分配任务的“管理线程”，而实际的请求和任务通常交由所谓“工作者线程”处理。通常多线程模型下，每个线程既是I/O线程又是工作者线程。所以这里讨论的是，单I/O线程+多工作者线程的模型，这也是最常用的一种服务器并发模型。我所在的项目中的server代码中，这种模型随处可见。它还有个名字，叫“半同步/半异步“模型，同时，这种模型也是生产者/消费者（尤其是多消费者）模型的一种表现。
这种架构主要是基于I/O多路复用的思想（主要是epoll，select/poll已过时），通过单线程I/O多路复用，可以达到高效并发，同时避免了多线程I/O来回切换的各种开销，思路清晰，易于管理，而基于线程池的多工作者线程，又可以充分发挥和利用多线程的优势，利用线程池，进一步提高资源复用性和避免产生过多线程。
epoll是linux下高并发服务器的完美方案，因为是基于事件触发的，所以比select快的不只是一个数量级。
单线程epoll，触发量可达到15000，但是加上业务后，因为大多数业务都与数据库打交道，所以就会存在阻塞的情况，这个时候就必须用多线程来提速。
java多线程有哪些实际的应用场景
多线程使用的主要目的在于：
1、吞吐量：你做WEB，容器帮你做了多线程，但是他只能帮你做请求层面的。简单的说，可能就是一个请求一个线程。或多个请求一个线程。如果是单线程，那同时只能处理一个用户的请求。
2、伸缩性：也就是说，你可以通过增加CPU核数来提升性能。如果是单线程，那程序执行到死也就利用了单核，肯定没办法通过增加CPU核数来提升性能。鉴于你是做WEB的，第1点可能你几乎不涉及。那这里我就讲第二点吧。
--举个简单的例子：假设有个请求，这个请求服务端的处理需要执行3个很缓慢的IO操作（比如数据库查询或文件查询），那么正常的顺序可能是（括号里面代表执行时间）：
a、读取文件1 （10ms）
b、处理1的数据（1ms）
c、读取文件2 （10ms）
d、处理2的数据（1ms）
e、读取文件3 （10ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）
单线程总共就需要34ms。
那如果你在这个请求内，把ab、cd、ef分别分给3个线程去做，就只需要12ms了。
所以多线程不是没怎么用，而是，你平常要善于发现一些可优化的点。然后评估方案是否应该使用。假设还是上面那个相同的问题：但是每个步骤的执行时间不一样了。
a、读取文件1 （1ms）
b、处理1的数据（1ms）
c、读取文件2 （1ms）
d、处理2的数据（1ms）
e、读取文件3 （28ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）单线程总共就需要34ms。
如果还是按上面的划分方案（上面方案和木桶原理一样，耗时取决于最慢的那个线程的执行速度），在这个例子中是第三个线程，执行29ms。那么最后这个请求耗时是30ms。比起不用单线程，就节省了4ms。但是有可能线程调度切换也要花费个1、2ms。
因此，这个方案显得优势就不明显了，还带来程序复杂度提升。不太值得。那么现在优化的点，就不是第一个例子那样的任务分割多线程完成。而是优化文件3的读取速度。可能是采用缓存和减少一些重复读取。首先，假设有一种情况，所有用户都请求这个请求，那其实相当于所有用户都需要读取文件3。
那你想想，100个人进行了这个请求，相当于你花在读取这个文件上的时间就是28×100=2800ms了。那么，如果你把文件缓存起来，那只要第一个用户的请求读取了，第二个用户不需要读取了，从内存取是很快速的，可能1ms都不到。
看起来好像还不错，建立一个文件名和文件数据的映射。如果读取一个map中已经存在的数据，那么就不不用读取文件了。可是问题在于，Servlet是并发，上面会导致一个很严重的问题，死循环。因为，HashMap在并发修改的时候，可能是导致循环链表的构成！！！（具体你可以自行阅读HashMap源码）如果你没接触过多线程，可能到时候发现服务器没请求也巨卡，也不知道什么情况！好的，那就用ConcurrentHashMap，正如他的名字一样，他是一个线程安全的HashMap，这样能轻松解决问题。
这样真的解决问题了吗，这样虽然只要有用户访问过文件a，那另一个用户想访问文件a，也会从fileName2Data中拿数据，然后也不会引起死循环。可是，如果你觉得这样就已经完了，那你把多线程也想的太简单了，骚年！你会发现，1000个用户首次访问同一个文件的时候，居然读取了1000次文件（这是最极端的，可能只有几百）。What the fuckin hell!!!难道代码错了吗，难道我就这样过我的一生！好好分析下。Servlet是多线程的，那么上面注释的“偶然”，这是完全有可能的，因此，这样做还是有问题。因此，可以自己简单的封装一个任务来处理。
以上所有代码都是直接在bbs打出来的，不保证可以直接运行。
多线程最多的场景：web服务器本身；各种专用服务器（如游戏服务器）；多线程的常见应用场景：
1、后台任务，例如：定时向大量（100w以上）的用户发送邮件；
2、异步处理，例如：发微博、记录日志等；
3、分布式计算
在java中，每一个线程有一块工作内存区，其中存放着被所有线程共享的主内存中的变量的值的拷贝。当线程执行时，它在自己的工作内存中操作这些变量。
为了存取一个共享的变量，一个线程通常先获取锁定并且清除它的工作内存区，这保证该共享变量从所有线程的共享内存区正确地装入到线程的工作内存区，当线程解锁时保证该工作内存区中变量的值协会到共享内存中。
当一个线程使用某一个变量时，不论程序是否正确地使用线程同步操作，它获取的值一定是由它本身或者其他线程存储到变量中的值。例如，如果两个线程把不同的值或者对象引用存储到同一个共享变量中，那么该变量的值要么是这个线程的，要么是那个线程的，共享变量的值不会是由两个线程的引用值组合而成。
一个变量时Java程序可以存取的一个地址，它不仅包括基本类型变量、引用类型变量，而且还包括数组类型变量。保存在主内存区的变量可以被所有线程共享，但是一个线程存取另一个线程的参数或者局部变量时不可能的，所以开发人员不必担心局部变量的线程安全问题。
volatile变量–多线程间可见
由于每个线程都有自己的工作内存区，因此当一个线程改变自己的工作内存中的数据时，对其他线程来说，可能是不可见的。为此，可以使用volatile关键字破事所有线程军读写内存中的变量，从而使得volatile变量在多线程间可见。
声明为volatile的变量可以做到如下保证：
1、其他线程对变量的修改，可以及时反应在当前线程中；2、确保当前线程对volatile变量的修改，能及时写回到共享内存中，并被其他线程所见；3、使用volatile声明的变量，编译器会保证其有序性。
同步关键字synchronized
同步关键字synchronized是Java语言中最为常用的同步方法之一。在JDK早期版本中，synchronized的性能并不是太好，值适合于锁竞争不是特别激烈的场合。在JDK6中，synchronized和非公平锁的差距已经缩小。更为重要的是，synchronized更为简洁明了，代码可读性和维护性比较好。
锁定一个对象的方法：
当method()方法被调用时，调用线程首先必须获得当前对象所，若当前对象锁被其他线程持有，这调用线程会等待，犯法结束后，对象锁会被释放，以上方法等价于下面的写法：
其次，使用synchronized还可以构造同步块，与同步方法相比，同步块可以更为精确控制同步代码范围。一个小的同步代码非常有离与锁的快进快出，从而使系统拥有更高的吞吐量。
synchronized也可以用于static函数：
这个地方一定要注意，synchronized的锁是加在当前Class对象上，因此，所有对该方法的调用，都必须获得Class对象的锁。
虽然synchronized可以保证对象或者代码段的线程安全，但是仅使用synchronized还是不足以控制拥有复杂逻辑的线程交互。为了实现多线程间的交互，还需要使用Object对象的wait()和notify()方法。
典型用法：
在使用wait()方法前，需要获得对象锁。在wait()方法执行时，当前线程或释放obj的独占锁，供其他线程使用。
当等待在obj上线程收到obj.notify()时，它就能重新获得obj的独占锁，并继续运行。注意了，notify()方法是随机唤起等待在当前对象的某一个线程。
下面是一个阻塞队列的实现：
synchronized配合wait()、notify()应该是Java开发者必须掌握的基本技能。
Reentrantlock重入锁
Reentrantlock称为重入锁。它比synchronized拥有更加强大的功能，它可以中断、可定时。在高并发的情况下，它比synchronized有明显的性能优势。
Reentrantlock提供了公平和非公平两种锁。公平锁是对锁的获取是先进先出，而非公平锁是可以插队的。当然从性能上分析，非公平锁的性能要好得多。因此，在无特殊需要，应该优选非公平锁，但是synchronized提供锁业不是绝对公平的。Reentrantlock在构造的时候可以指定锁是否公平。
在使用重入锁时，一定要在程序最后释放锁。一般释放锁的代码要写在finally里。否则，如果程序出现异常，Loack就永远无法释放了。synchronized的锁是JVM最后自动释放的。
经典使用方式如下：
Reentrantlock提供了非常丰富的锁控制功能，灵活应用这些控制方法，可以提高应用程序的性能。不过这里并非是极力推荐使用Reentrantlock。重入锁算是JDK中提供的高级开发工具。
ReadWriteLock读写锁
读写分离是一种非常常见的数据处理思想。在sql中应该算是必须用到的技术。ReadWriteLock是在JDK5中提供的读写分离锁。读写分离锁可以有效地帮助减少锁竞争，以提升系统性能。读写分离使用场景主要是如果在系统中，读操作次数远远大于写操作。使用方式如下：
Condition对象
Conditiond对象用于协调多线程间的复杂协作。主要与锁相关联。通过Lock接口中的newCondition()方法可以生成一个与Lock绑定的Condition实例。Condition对象和锁的关系就如用Object.wait()、Object.notify()两个函数以及synchronized关键字一样。
这里可以把ArrayBlockingQueue的源码摘出来看一下：
此实例简单实现了一个对象池，对象池最大容量为100。因此，当同时有100个对象请求时，对象池就会出现资源短缺，未能获得资源的线程就需要等待。当某个线程使用对象完毕后，就需要将对象返回给对象池。此时，由于可用资源增加，因此，可以激活一个等待该资源的线程。
ThreadLocal线程局部变量
在刚开始接触ThreadLocal，笔者很难理解这个线程局部变量的使用场景。当现在回过头去看，ThreadLocal是一种多线程间并发访问变量的解决方案。与synchronized等加锁的方式不同，ThreadLocal完全不提供锁，而使用了以空间换时间的手段，为每个线程提供变量的独立副本，以保障线程安全，因此它不是一种数据共享的解决方案。
ThreadLocal是解决线程安全问题一个很好的思路，ThreadLocal类中有一个Map，用于存储每一个线程的变量副本，Map中元素的键为线程对象，而值对应线程的变量副本，由于Key值不可重复，每一个“线程对象”对应线程的“变量副本”，而到达了线程安全。
特别值得注意的地方，从性能上说，ThreadLocal并不具有绝对的又是，在并发量不是很高时，也行加锁的性能会更好。但作为一套与锁完全无关的线程安全解决方案，在高并发量或者所竞争激烈的场合，使用ThreadLocal可以在一定程度上减少锁竞争。
下面是一个ThreadLocal的简单使用：
输出结果：
输出的结果信息可以发现每个线程所产生的序号虽然都共享同一个TestNum实例，但它们并没有发生相互干扰的情况，而是各自产生独立的序列号，这是因为ThreadLocal为每一个线程提供了单独的副本。
锁的性能和优化
“锁”是最常用的同步方法之一。在平常开发中，经常能看到很多同学直接把锁加很大一段代码上。还有的同学只会用一种锁方式解决所有共享问题。显然这样的编码是让人无法接受的。特别的在高并发的环境下，激烈的锁竞争会导致程序的性能下降德更加明显。因此合理使用锁对程序的性能直接相关。
1、线程的开销
在多核情况下，使用多线程可以明显提高系统的性能。但是在实际情况中，使用多线程的方式会额外增加系统的开销。相对于单核系统任务本身的资源消耗外，多线程应用还需要维护额外多线程特有的信息。比如，线程本身的元数据，线程调度，线程上下文的切换等。
2、减小锁持有时间
在使用锁进行并发控制的程序中，当锁发生竞争时，单个线程对锁的持有时间与系统性能有着直接的关系。如果线程持有锁的时间很长，那么相对地，锁的竞争程度也就越激烈。因此，在程序开发过程中，应该尽可能地减少对某个锁的占有时间，以减少线程间互斥的可能。比如下面这一段代码：
此实例如果只有mutexMethod()方法是有同步需要的，而在beforeMethod(),和afterMethod()并不需要做同步控制。如果beforeMethod(),和afterMethod()分别是重量级的方法，则会花费较长的CPU时间。在这个时候，如果并发量较大时，使用这种同步方案会导致等待线程大量增加。因为当前执行的线程只有在执行完所有任务后，才会释放锁。
下面是优化后的方案，只在必要的时候进行同步，这样就能明显减少线程持有锁的时间，提高系统的吞吐量。代码如下：
3、减少锁粒度
减小锁粒度也是一种削弱多线程锁竞争的一种有效手段，这种技术典型的使用场景就是ConcurrentHashMap这个类。在普通的HashMap中每当对集合进行add()操作或者get()操作时，总是获得集合对象的锁。这种操作完全是一种同步行为，因为锁是在整个集合对象上的，因此，在高并发时，激烈的锁竞争会影响到系统的吞吐量。
如果看过源码的同学应该知道HashMap是数组+链表的方式做实现的。ConcurrentHashMap在HashMap的基础上将整个HashMap分成若干个段(Segment)，每个段都是一个子HashMap。如果需要在增加一个新的表项，并不是将这个HashMap加锁，二十搜线根据hashcode得到该表项应该被存放在哪个段中，然后对该段加锁，并完成put()操作。这样，在多线程环境中，如果多个线程同时进行写入操作，只要被写入的项不存在同一个段中，那么线程间便可以做到真正的并行。具体的实现希望读者自己花点时间读一读ConcurrentHashMap这个类的源码，这里就不再做过多描述了。
4、锁分离
在前面提起过ReadWriteLock读写锁，那么读写分离的延伸就是锁的分离。同样可以在JDK中找到锁分离的源码LinkedBlockingQueue。
这里需要说明一下的就是，take()和put()函数是相互独立的，它们之间不存在锁竞争关系。只需要在take()和put()各自方法内部分别对takeLock和putLock发生竞争。从而，削弱了锁竞争的可能性。
5、锁粗化
上面说到的减小锁时间和粒度，这样做就是为了满足每个线程持有锁的时间尽量短。但是，在粒度上应该把握一个度，如果对用一个锁不停地进行请求、同步和释放，其本身也会消耗系统宝贵的资源，反而加大了系统开销。
我们需要知道的是，虚拟机在遇到一连串连续的对同一锁不断进行请求和释放的操作时，便会把所有的锁操作整合成对锁的一次请求，从而减少对锁的请求同步次数，这样的操作叫做锁的粗化。下面是一段整合实例演示：
JVM整合后的形式：
因此，这样的整合给我们开发人员对锁粒度的把握给出了很好的演示作用。
无锁的并行计算
上面花了很大篇幅在说锁的事情，同时也提到过锁是会带来一定的上下文切换的额外资源开销，在高并发时，”锁“的激烈竞争可能会成为系统瓶颈。因此，这里可以使用一种非阻塞同步方法。这种无锁方式依然能保证数据和程序在高并发环境下保持多线程间的一致性。
1、非阻塞同步/无锁非阻塞同步方式其实在前面的ThreadLocal中已经有所体现，每个线程拥有各自独立的变量副本，因此在并行计算时，无需相互等待。这里笔者主要推荐一种更为重要的、基于比较并交换（Compare And Swap）CAS算法的无锁并发控制方法。
CAS算法的过程：它包含3个参数CAS(V,E,N)。V表示要更新的变量，E表示预期值，N表示新值。仅当V值等于E值时，才会将V的值设为N，如果V值和E值不同，则说明已经有其他线程做了更新，则当前线程什么都不做。最后CAS返回当前V的真实值。CAS操作时抱着乐观的态度进行的，它总是认为自己可以成功完成操作。当多个线程同时使用CAS操作一个变量时，只有一个会胜出，并成功更新，其余俊辉失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理，CAS操作及时没有锁，也可以发现其他线程对当前线程的干扰，并且进行恰当的处理。
2、原子量操作
JDK的java.util.concurrent.atomic包提供了使用无锁算法实现的原子操作类，代码内部主要使用了底层native代码的实现。有兴趣的同学可以继续跟踪一下native层面的代码。这里就不贴表层的代码实现了。
下面主要以一个例子来展示普通同步方法和无锁同步的性能差距：
测试结果如下：
相信这样的测试结果将内部锁和非阻塞同步算法的性能差异体现的非常明显。因此我更推荐直接视同atomic下的这个原子类。
希望以上我的回答能帮到大家！
线程池处理流程是什么
提交任务后，线程池先判断线程数是否达到了核心线程数（corePoolSize）。如果未达到线程数，则创建核心线程处理任务；否则，就执行下一步；
接着线程池判断任务队列是否满了。如果没满，则将任务添加到任务队列中；否则，执行下一步；
接着因为任务队列满了，线程池就判断线程数是否达到了最大线程数。如果未达到，则创建非核心线程处理任务；否则，就执行饱和策略，默认会抛出RejectedExecutionException异常。
面试时，如何在众多Java工程师中脱颖而出
由于我经常受邀面试Java程序员，所以我来回答一下这个问题。
Java程序员有多个不同的从业方向，比如Web开发、大数据开发、Android开发以及各种后端开发等等，不同的开发方向需要具备不同的知识结构，同时不同的开发岗位（应用级程序员和研发级程序员）也有不同的要求。
对于参加面试的Java程序员来说，通常情况下需要注意以下几个方面：
第一：强调经验。对于科技公司来说，最为看重的内容之一就是项目经验，丰富的项目经验能够明显提升面试的成功率。对于Java程序员来说，比较有价值的项目经验包括大用户并发访问的经验、分布式处理的经验、事务处理经验、安全处理经验等等。另外，行业经验往往也比较重要，如果长时间深入某个领域，比如金融、通信等行业开发经验都会提升面试成功率。
第二：强调学习能力。学习能力也是用人单位非常看重的能力之一，尤其是面试初级程序员或者是主力程序员岗位。对于经验并不丰富的程序员来说，如果想打动面试官，一定要强调自己的学习能力。可以通过一个项目案例来说明自己的学习能力，比如从零开始学习到完成一个项目经历了哪些学习和实验过程等等。
第三：强调知识结构。随着互联网行业的不断发展，科技公司对于程序员的知识结构有越来越多的要求，知识结构的丰富程度往往能对面试结果有重要的影响。知识结构有两个重点内容，第一个是要具备扎实的计算机基础知识，包括操作系统体系结构、计算机网络、算法设计等内容，另一方面就是目前流行的技术，包括大数据、云计算、物联网等方面的内容。
面试过程中一定要思维清晰，能够针对面试官的问题给出明确且肯定的回答，这也是一种自信的表现。
我从事互联网行业多年，目前也在带计算机专业的研究生，主要的研究方向集中在大数据和人工智能领域，我会陆续在头条写一些关于互联网技术方面的文章，感兴趣的朋友可以关注我，相信一定会有所收获。
如果有互联网方面的问题，也可以咨询我，谢谢！
java线程池怎么配置最好比如阻塞队列的选择
我个人感觉，主要是根据业务场景和机器数量来配置。比如核心线程数，我一般是取当前机器核数。不过如果遇到高并发量的情况，还是要多设定一些为好。而队列，要结合业务来看，比如说，设置了无界队列，但是并发请求量巨大，就可能导致内存飙升，最后oom。有界队列，要看你设置超过队列数量后任务的处理方式，直接抛弃，还是重试等。这也是根据业务本身来决定的。
以上内容，乃个人愚见，仅供参考。
