「阿里不推荐java线程池」Java常见的线程池
今天给各位分享阿里不推荐java线程池的知识，其中也会对Java常见的线程池进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
4. 线程池使用
线程池: 如果线程的数量很多,并且每个线程都是执行一个时间很短的任务就结束,这样频繁创建线程会大大增加系统的开销,因为创建和消毁线程都需要资源和时间的
简单实例:
分析:
以上就是直接new一个线程池出来运行,但是阿里开发手册禁止使用该方法来启动一个线程池.而推荐使用ThreadPoolExecutor来创建
先看ThreadPoolExecutor源码
构造器提供了的参数我们来分析一下
阿里推荐我们使用ThreadPoolExecutor来创建线程池,原因是这样创建线程比较灵活,可以根据自己的业务去定制线程池
ThreadPoolExecutor源码这里就先不讲解放到下篇文章讲解,这里说说ThreadPoolExecutor的执行过程,如何触发maximumPoolSize的执行线程启动
上例子:
以上的执行结果我拷贝一定出来分析:
看到执行结果的朋友们都惊呆了,为什么这执行顺序1,2,3执行的一下子跳到54个任务,然后处理完62的任务又执行4以下的任务,接下来的顺序就正常了
原因: 定义线程池是核心为3个线程,所以执行了1-3任务,没问题!到后面线程pool-4-thread-(4-12)都是 maximumPoolSize - 核心线程 = 要创建的临时线程数.这里是 重点 ,这些临时线程是当你工作队列满了的情况才创建出来的, 而工作队列里面的任务是不先处理,而且让工作队列存放不下的任务,直接交给临时线程处理,所以临时线程直接执行了54-62任务,然后处理完之后在去队列里面从头获取任务执行,所以执行完62任务后后面的执行顺序就正常了.运行到了下面,直接任务数到了29381082时,这里我是启动了任务执行处理不来是或工作队列满了时,任务丢弃了,所以存到工作队列任务的数字就是29381082,然后就通过线程去获取任务指定任务
线程池的使用
首先看看 阿里java规范 中对线程池使用的规范
不允许使用Executors创建线程池，创建的线程池数量可以为Integer.MAX_VALUE,可能导致OOM
推荐使用
ThreadPoolExecutor创建
看看其4构造方法
看参数最多的一个，上面的都是调这个方法
翻译一下
ThreadPoolExecutor(核心线程大小, 最大线程数,线程保持时间,保持时间单位, 缓存队列,线程工厂,拒绝策略)
前四个比较容易理解，看后面几个就好了
缓存队列：任务多的时候，没有多余线程执行任务，这些任务去队列排队，先进先出的原则，这里队列大小是有限制的，队排满了怎么办，用后面的拒绝策略来处理
线程工厂：
继承java.util.concurrent.ThreadFactory,下面是可用的两个工厂
拒绝策略：队列满了，后面的任务排不进去怎么处理，四种策略
1.AbortPolicy（终止策略）
这是一个处理器针对被拒绝的任务 直接抛出RejectedExecutionException异常（任务无法执行抛出异常）
2.DiscardPolicy（丢弃策略）
什么都不做，也不抛出异常
3.DiscardOldestPolicy（丢弃旧任务策略）
一种被拒绝任务的处理程序，它丢弃（workQueue队列）最老的未被处理请求（队列最先被放进去的任务），然后调用e.execute(r)重试执行当前任务（注意依然要走流程），除非执行器关闭，在这种情况下任务被丢弃。
4.CallerRunsPolicy（调用方运行策略）
被拒绝任务的处理程序，它直接由提交任务的线程来运行这个提交的任务，除非executor已关闭，在这种情况下任务被丢弃。
测试一下
执行结果
1、核心线程先初始化一个线程
2、第1个任务直接给线程
3、第2-6加入队列，装满了
4、第7-10需创建线程用于执行任务
5、到此队列5个和线程五个一起最多处理10任务，第11个任务拒绝处理，等待中...
6、继续执行，利用释放的线程和队列继续处理（优先使用线程，没有加入队列）...
阿里巴巴推荐创建线程池方式
使用ThreadPoolExecutor创建
JDK1.8中构造方法如下：
keepAliveTime即空闲线程（大于corePoolSize 小于maximumPoolSize 的线程）保持存活的时间，超出这个时间，线程将被销毁。
java 多线程怎么深入？
并发与并行
并行，表示两个线程同时做事情。
并发，表示一会做这个事情，一会做另一个事情，存在着调度。单核 CPU 不可能存在并行（微观上）。
临界区
临界区用来表示一种公共资源或者说是共享数据，可以被多个线程使用。但是每一次，只能有一个线程使用它，一旦临界区资源被占用，其他线程要想使用这个资源，就必须等待。
阻塞与非阻塞
阻塞和非阻塞通常用来形容多线程间的相互影响。比如一个线程占用了临界区资源，那么其它所有需要这个资源的线程就必须在这个临界区中进行等待，等待会导致线程挂起。这种情况就是阻塞。
此时，如果占用资源的线程一直不愿意释放资源，那么其它所有阻塞在这个临界区上的线程都不能工作。阻塞是指线程在操作系统层面被挂起。阻塞一般性能不好，需大约8万个时钟周期来做调度。
非阻塞则允许多个线程同时进入临界区。
死锁
死锁是进程死锁的简称，是指多个进程循环等待他方占有的资源而无限的僵持下去的局面。
活锁
假设有两个线程1、2，它们都需要资源 A/B，假设1号线程占有了 A 资源，2号线程占有了 B 资源；由于两个线程都需要同时拥有这两个资源才可以工作，为了避免死锁，1号线程释放了 A 资源占有锁，2号线程释放了 B 资源占有锁；此时 AB 空闲，两个线程又同时抢锁，再次出现上述情况，此时发生了活锁。
简单类比，电梯遇到人，一个进的一个出的，对面占路，两个人同时往一个方向让路，来回重复，还是堵着路。
如果线上应用遇到了活锁问题，恭喜你中奖了，这类问题比较难排查。
饥饿
饥饿是指某一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行。
线程的生命周期
在线程的生命周期中，它要经历创建、可运行、不可运行几种状态。
创建状态
当用 new 操作符创建一个新的线程对象时，该线程处于创建状态。
处于创建状态的线程只是一个空的线程对象，系统不为它分配资源。
可运行状态
执行线程的 start() 方法将为线程分配必须的系统资源，安排其运行，并调用线程体——run()方法，这样就使得该线程处于可运行状态（Runnable）。
这一状态并不是运行中状态（Running），因为线程也许实际上并未真正运行。
不可运行状态
当发生下列事件时，处于运行状态的线程会转入到不可运行状态：
调用了 sleep() 方法；
线程调用 wait() 方法等待特定条件的满足；
线程输入/输出阻塞；
返回可运行状态；
处于睡眠状态的线程在指定的时间过去后；
如果线程在等待某一条件，另一个对象必须通过 notify() 或 notifyAll() 方法通知等待线程条件的改变；
如果线程是因为输入输出阻塞，等待输入输出完成。
线程的优先级
线程优先级及设置
线程的优先级是为了在多线程环境中便于系统对线程的调度，优先级高的线程将优先执行。一个线程的优先级设置遵从以下原则：
线程创建时，子继承父的优先级；
线程创建后，可通过调用 setPriority() 方法改变优先级；
线程的优先级是1-10之间的正整数。
线程的调度策略
线程调度器选择优先级最高的线程运行。但是，如果发生以下情况，就会终止线程的运行：
线程体中调用了 yield() 方法，让出了对 CPU 的占用权；
线程体中调用了 sleep() 方法，使线程进入睡眠状态；
线程由于 I/O 操作而受阻塞；
另一个更高优先级的线程出现；
在支持时间片的系统中，该线程的时间片用完。
单线程创建方式
单线程创建方式比较简单，一般只有两种方式：继承 Thread 类和实现 Runnable 接口；这两种方式比较常用就不在 Demo 了，但是对于新手需要注意的问题有：
不管是继承 Thread 类还是实现 Runable 接口，业务逻辑是写在 run 方法里面，线程启动的时候是执行 start() 方法；
开启新的线程，不影响主线程的代码执行顺序也不会阻塞主线程的执行；
新的线程和主线程的代码执行顺序是不能够保证先后的；
对于多线程程序，从微观上来讲某一时刻只有一个线程在工作，多线程目的是让 CPU 忙起来；
通过查看 Thread 的源码可以看到，Thread 类是实现了 Runnable 接口的，所以这两种本质上来讲是一个；
PS：平时在工作中也可以借鉴这种代码结构，对上层调用来讲提供更多的选择，作为服务提供方核心业务归一维护
为什么要用线程池
通过上面的介绍，完全可以开发一个多线程的程序，为什么还要引入线程池呢。主要是因为上述单线程方式存在以下几个问题：
线程的工作周期：线程创建所需时间为 T1，线程执行任务所需时间为 T2，线程销毁所需时间为 T3，往往是 T1+T3 大于 T2，所有如果频繁创建线程会损耗过多额外的时间；
如果有任务来了，再去创建线程的话效率比较低，如果从一个池子中可以直接获取可用的线程，那效率会有所提高。所以线程池省去了任务过来，要先创建线程再去执行的过程，节省了时间，提升了效率；
线程池可以管理和控制线程，因为线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控；
线程池提供队列，存放缓冲等待执行的任务。
大致总结了上述的几个原因，所以可以得出一个结论就是在平时工作中，如果要开发多线程程序，尽量要使用线程池的方式来创建和管理线程。
通过线程池创建线程从调用 API 角度来说分为两种，一种是原生的线程池，另外该一种是通过 Java 提供的并发包来创建，后者比较简单，后者其实是对原生的线程池创建方式做了一次简化包装，让调用者使用起来更方便，但道理都是一样的。所以搞明白原生线程池的原理是非常重要的。
ThreadPoolExecutor
通过 ThreadPoolExecutor 创建线程池，API 如下所示：
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime,
TimeUnit unit,
BlockingQueueRunnable workQueue);
先来解释下其中的参数含义（如果看的比较模糊可以大致有个印象，后面的图是关键）。
corePoolSize
核心池的大小。
在创建了线程池后，默认情况下，线程池中并没有任何线程，而是等待有任务到来才创建线程去执行任务，除非调用了 prestartAllCoreThreads() 或者 prestartCoreThread() 方法，从这两个方法的名字就可以看出，是预创建线程的意思，即在没有任务到来之前就创建 corePoolSize 个线程或者一个线程。默认情况下，在创建了线程池后，线程池中的线程数为0，当有任务来之后，就会创建一个线程去执行任务，当线程池中的线程数目达到 corePoolSize 后，就会把到达的任务放到缓存队列当中。
maximumPoolSize
线程池最大线程数，这个参数也是一个非常重要的参数，它表示在线程池中最多能创建多少个线程。
keepAliveTime
表示线程没有任务执行时最多保持多久时间会终止。默认情况下，只有当线程池中的线程数大于 corePoolSize 时，keepAliveTime 才会起作用，直到线程池中的线程数不大于 corePoolSize，即当线程池中的线程数大于 corePoolSize 时，如果一个线程空闲的时间达到 keepAliveTime，则会终止，直到线程池中的线程数不超过 corePoolSize。
但是如果调用了 allowCoreThreadTimeOut(boolean) 方法，在线程池中的线程数不大于 corePoolSize 时，keepAliveTime 参数也会起作用，直到线程池中的线程数为0。
unit
参数 keepAliveTime 的时间单位。
workQueue
一个阻塞队列，用来存储等待执行的任务，这个参数的选择也很重要，会对线程池的运行过程产生重大影响，一般来说，这里的阻塞队列有以下这几种选择：ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue。
threadFactory
线程工厂，主要用来创建线程。
handler
表示当拒绝处理任务时的策略，有以下四种取值：
ThreadPoolExecutor.AbortPolicy：丢弃任务并抛出 RejectedExecutionException 异常；
ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常；
ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）；
ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务。
上面这些参数是如何配合工作的呢？请看下图：
请点击输入图片描述
注意图上面的序号。
简单总结下线程池之间的参数协作分为以下几步：
线程优先向 CorePool 中提交；
在 Corepool 满了之后，线程被提交到任务队列，等待线程池空闲；
在任务队列满了之后 corePool 还没有空闲，那么任务将被提交到 maxPool 中，如果 MaxPool 满了之后执行 task 拒绝策略。
流程图如下：
请点击输入图片描述
image
以上就是原生线程池创建的核心原理。除了原生线程池之外并发包还提供了简单的创建方式，上面也说了它们是对原生线程池的一种包装，可以让开发者简单快捷的创建所需要的线程池。
Executors
newSingleThreadExecutor
创建一个线程的线程池，在这个线程池中始终只有一个线程存在。如果线程池中的线程因为异常问题退出，那么会有一个新的线程来替代它。此线程池保证所有任务的执行顺序按照任务的提交顺序执行。
newFixedThreadPool
创建固定大小的线程池。每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。
newCachedThreadPool
可根据实际情况，调整线程数量的线程池，线程池中的线程数量不确定，如果有空闲线程会优先选择空闲线程，如果没有空闲线程并且此时有任务提交会创建新的线程。在正常开发中并不推荐这个线程池，因为在极端情况下，会因为 newCachedThreadPool 创建过多线程而耗尽 CPU 和内存资源。
newScheduledThreadPool
此线程池可以指定固定数量的线程来周期性的去执行。比如通过 scheduleAtFixedRate 或者 scheduleWithFixedDelay 来指定周期时间。
PS：另外在写定时任务时（如果不用 Quartz 框架），最好采用这种线程池来做，因为它可以保证里面始终是存在活的线程的。
推荐使用 ThreadPoolExecutor 方式
在阿里的 Java 开发手册时有一条是不推荐使用 Executors 去创建，而是推荐去使用 ThreadPoolExecutor 来创建线程池。
这样做的目的主要原因是：使用 Executors 创建线程池不会传入核心参数，而是采用的默认值，这样的话我们往往会忽略掉里面参数的含义，如果业务场景要求比较苛刻的话，存在资源耗尽的风险；另外采用 ThreadPoolExecutor 的方式可以让我们更加清楚地了解线程池的运行规则，不管是面试还是对技术成长都有莫大的好处。
改了变量，其他线程可以立即知道。保证可见性的方法有以下几种：
volatile
加入 volatile 关键字的变量在进行汇编时会多出一个 lock 前缀指令，这个前缀指令相当于一个内存屏障，内存屏障可以保证内存操作的顺序。当声明为 volatile 的变量进行写操作时，那么这个变量需要将数据写到主内存中。
由于处理器会实现缓存一致性协议，所以写到主内存后会导致其他处理器的缓存无效，也就是线程工作内存无效，需要从主内存中重新刷新数据。
普通公司员工的编程水平与阿里巴巴有多大差距？
作为一个编程十几年的老程序员，虽然没有进过阿里巴巴，中间换工作时候也拒绝过百度和腾讯的offer，选择了一个更适合自己的互联网公司，编程水平主要决定因素还是和本人基本功有着极大的环境，前几天回答了一个大公司和小公司编码水平谁高谁低的问题，有外在因素影响但主要还是自身，自己没有决心提升自己的编码水平，外界环境再好也没多大意义。
像阿里巴巴这种大公司由于职位安排的比较饱满，正常来讲代码的提交都需要leader的审核通过，在一定程度上能极大的提高代码的质量，在审核机制上会更加严格，并且在测试把关上也会更加严格，普通的小公司在人员配置上可能稍微少一些，会在把关上差一点，严格规范的制度在一定程度上能促进程序员更深层的改进，但本质上还是自身想不想让自己变得更加优秀，愿意不愿意让自己提升的更加快速。
其实提到阿里巴巴这种大公司主要还是人心态问题，觉得大公司一定要比小公司规范，换做经历过大公司的人，还想着在里面自己只是一个螺丝钉，还想着去小型公司让自己发挥的更加彻底，小公司的人又向往着大公司的待遇以及规范。如同没有结婚的人，总想着走进围城，进入的人又羡慕没有结婚的多自由，其实来来回回也就那回事。
曾经也是为了进入大公司舍弃了一个中型公司部门技术经理的职位，现在想象其实很不值当，进入一个成熟的大公司，自己做出的贡献只是沧海一粟，想要向上走特别难，而真正的机会还是在创业公司或者中小型公司，当然这些东西需要亲身体验才能感受到，在年轻气盛阶段很难体味到，就是觉得自己所做的选择是对的，实践辨真知。
希望能帮到你。
以我自身的经历来回答吧！我是做java开发的，在没进阿里之前，我在外面其他公司干了四年。头两年干的最多的事情就是直接把业务翻译成代码，做的最多的事情就是curd。工程化以及结构化设计根本不存在的，什么性能、可扩展性、易用性、可维护性通通不考虑。把功能实现了就可以了，活脱脱的把面向对象的语言使用成了面向过程编程。(因为大家都这样干)主要还是因为刚毕业在这家公司做erp系统，功能可以用就不管了。接下来的两年换了一家电商公司，这也是一个天坑，代码跟 山差不多，我进去做库存的，第一件事情就是熟悉了业务然后进行了重构。前面做这一块的人都差不多走光了，模型抽象，领域分层，模块分层一顿操作下来自我感觉良好。但是叠加了两年的业务以后，妈的差不多也是 山了，为了业务快速迭代牺牲一些也是能理解的。然后我走了[捂脸]。
进入了阿里，我是做中台开发的。这里最喜欢干的就是重复造轮子，干啥都要讲究高可用、可复用、可扩展、可维护、可读性……写代码大抵是这样的一个接口进去写接口一般先上熔断降级开关、分布式锁，然后就是加缓存，接着业务就用领域模型+泛化抽象模型+工厂设计模式+策略模式 这一顿操作下来后，为了支持扩展性还得定制spi扩展点提供扩展。一个业务功能的代码完全是割裂的状态。不过项目跟代码的质量跟之前的公司比确实上升不少。只能说环境的影响很大吧
虽然没有去过大厂，但还是想强答一下，毕竟有不少认识的朋友在BAT工作或工作过。
我的看法是：BAT的牛人多，普通人也多，虽然他们不是每个人都能达到令人仰望的技术水平，但毕竟平台高，所以眼光会变得宽阔；代码要求更为严格，所以普通的程序员也会被逼变得更优秀；身边的牛人多，普通的程序员也会受到影响，提升的更快。
正好今天看到一篇文章，是讲去阿里的面试经历，也分享给大家，看看自己离着【进】阿里还有多大的差距。
Java多线程
线程池的原理，为什么要创建线程池？
线程的生命周期，什么时候会出现僵死进程；
什么实现线程安全，如何实现线程安全；
创建线程池有哪几个核心参数？ 如何合理配置线程池的大小？
synchronized、volatile区别、synchronized锁粒度、模拟死锁场景、原子性与可见性；
JVM相关
JVM内存模型，GC机制和原理；GC分哪两种；什么时候会触发Full GC？
JVM里的有几种classloader，为什么会有多种？
什么是双亲委派机制？介绍一些运作过程，双亲委派模型的好处；(这个我真的不会...)
什么情况下我们需要破坏双亲委派模型；
常见的JVM调优方法有哪些？可以具体到调整哪个参数，调成什么值？
JVM虚拟机内存划分、类加载器、垃圾收集算法、垃圾收集器、class文件结构是如何解析的；
Java扩展
红黑树的实现原理和应用场景；
NIO是什么？适用于何种场景？
Java9比Java8改进了什么；
HashMap内部的数据结构是什么？底层是怎么实现的？
说说反射的用途及实现，反射是不是很慢，我们在项目中是否要避免使用反射；
说说自定义注解的场景及实现；
List和Map区别，Arraylist与LinkedList区别，ArrayList与Vector 区别；
Spring
Spring AOP的实现原理和场景；（应用场景很重要）
Spring bean的作用域和生命周期；
Spring Boot比Spring做了哪些改进？ Spring 5比Spring4做了哪些改进；（惭愧呀，我们还在用Spring4，高版本的没关心过）
Spring IOC是什么？优点是什么？
SpringMVC、动态代理、反射、AOP原理、事务隔离级别；
中间件
Dubbo完整的一次调用链路介绍；
Dubbo支持几种负载均衡策略？
Dubbo Provider服务提供者要控制执行并发请求上限，具体怎么做？
Dubbo启动的时候支持几种配置方式？
了解几种消息中间件产品？各产品的优缺点介绍；
消息中间件如何保证消息的一致性和如何进行消息的重试机制？
Spring Cloud熔断机制介绍；
Spring Cloud对比下Dubbo，什么场景下该使用Spring Cloud？
数据库篇
锁机制介绍：行锁、表锁、排他锁、共享锁；
乐观锁的业务场景及实现方式；
事务介绍，分布式事物的理解，常见的解决方案有哪些，什么事两阶段提交、三阶段提交；
MySQL记录binlog的方式主要包括三种模式？每种模式的优缺点是什么？
MySQL锁，悲观锁、乐观锁、排它锁、共享锁、表级锁、行级锁；
分布式事务的原理2阶段提交，同步异步阻塞非阻塞；
数据库事务隔离级别，MySQL默认的隔离级别、Spring如何实现事务、
JDBC如何实现事务、嵌套事务实现、分布式事务实现；
SQL的整个解析、执行过程原理、SQL行转列；
Redis
Redis为什么这么快？redis采用多线程会有哪些问题？
Redis支持哪几种数据结构；
Redis跳跃表的问题；
Redis单进程单线程的Redis如何能够高并发?
Redis如何使用Redis实现分布式锁？
Redis分布式锁操作的原子性，Redis内部是如何实现的？
看完了有什么感想，自己和BAT的要求有差距么？
反正我觉得自己想要面试通过是有些困难，很多框架新版本的特性都没有了解过，看来年前还得抽时间学些一下了。
大公司如bat大部分普通程序员，由于做的太专一了，基本上在某一方面做得不错，整体能力差很远，但是自己觉得啥都行。
这么比喻吧，如果说把程序员比作厨师。
普通公司的程序员基本上是各个饭店的大厨，啥菜都会做。
bat是御膳房，程序员什么大菜都见过，但基本上一个大菜也做不了。很多人就是御膳房后勤部切葱花大队的切葱花手
普通公司员工的编程水平与阿里巴巴有多大差距？要说阿里巴巴每个程序员都牛逼得不行那也是扯淡，普通公司牛逼的程序员也不少，这本身就没有一定的定论。
在阿里巴巴这样公司的程序员来说，应该比较幸运的是能够遇到大型互联网软件的开发，比如像架构设计、场景设计等，这对于很多程序员来说应该可以开眼界，参与其中也能锻炼自己。同样的，很多大型软件公司虽然没有阿里这样的场景，但同样也有自己特殊的应用设计、场景在阿里也见不到。
而对于单个程序员的编码水平来说，普通公司与阿里的程序员可能根本就没啥区别。普通公司里也有严格按规范、严格按流程、严格测试等来做软件，进入里面同样可以遇到大牛带领项目、大牛的传帮带等，耳闻目染再加努力实践，这些程序员的水平并不能说就比阿里的程序员差。当然，阿里这样的名气不外乎就是进入时经过了严格的挑选，这些程序员的基础都是不错的，但真正要有水平，那还得除了环境也得要靠自己努力。
但大公司程序员与小公司的程序员还是有一些差异的。小公司人员可能接触的项目基本不大，而像万金油那样啥都接触到一些能搞一些，但深度却不够。比如小公司的程序员今天搞Java编码，可能下个项目就去搞PHP，再下个项目又去搞python等，今天是程序，每隔两个月可能又是下个项目的设计者、Leader等有可能。但恰恰在某一项编码上却又不像某些大公司的程序员那样一个萝卜一个坑儿，又专又精。
另外小公司的开发流程及规范都不够，有些甚至是只要搞出来能运行就可以，所以章法上不像大公司一样规范。甚至有些都没有严格的测试就到客户那里去上线，让客户去当小白鼠，做一个败一个。
所以作为程序员最好是能开始到大公司去学习锻炼规范的软件开发那是很有益的。至于是不是阿里倒不一定，能进入阿里当然好。而说到编码水平，绝大部分还是要靠自己的努力，特别是培养思维能力、基础知识、见多识广、多加实践与交流，对自己编码能力提升是必不可少的。天赋程序员确实有，但绝大部分程序员要说天赋都谈不上，大部分也就是上面几项用了更多的时间吧。
能力上，bat的程序员远超小公司程序员；不要相信那些什么小公司的程序员什么都要做所以咋样咋样，大公司就只是一颗小螺丝钉，自欺欺人而已；大公司的程序员天赋就强于小公司的程序员，技术靠的是天赋+努力，天赋远远重要于努力，你不信那就是你傻
在阿里三年的老人说一下。主要是能够获取和见识到小公司不能给你的经验，场景和挑战
说到电脑的编程，对于学计算机的人来说真的是一件非常头疼的事情，每天的编程工作都要面对各种各样的字母，各种各样的特殊符号，一般人看见也就只能一懵一懵的。每个程序员之间也都是有技术好技术低的，并且程序员在选择公司的时候也面临很大的困难。
现在 社会 上找工作的人都有一个普遍的现象，在小公司工作的人都想去大公司，在大公司工作的人想去中小企业工作。每个程序员都想得到一个展现自己的机会，让自己所学的知识有所用武之地。能力较强的程序员就去了大公司，能力有点差异的就去了中小企业，但是这两者在各自公司的发展并不一样。
在中小企业工作程序员有可能会在公司有更大的发展空间，在大企业里面有着许多优秀的程序员，就像是阿里巴巴，有可能在这个团队里面自己的能力不能跟好的发挥。有一点要清楚，技术高的人在一起会越来越优秀，他们各自有各自的特点，都会互相学习互相进步，前进的动力也大。普通公司的程序员自我提升的空间较小，没有像阿里巴巴这样的公司程序员水平高。
大企业对程序员的要求也很高，这些程序员所要面对的困难也非常大，逼迫着自己去提升自身的能力，如果两个技术相匹配的程序员一个去普通企业，一个去阿里巴巴这样的大公司，在工作一段时间后，在阿里巴巴工作的程序员要远远超过普通公司的程序员。虽然大公司的程序员想去中小公司，但是对他们更是一种较大的损失。
更多优质内容，请持续关注镁客网~~
大公司的程序员，在代码专精度方面确实超过小公司程序员。他们往往在技术的某一方面钻研颇深，在代码实践上做得细腻完美无可挑剔。小公司程序员在专精度上不如bat程序员，因为大环境使然，无法让一个程序员只负责某一模块的代码，他们往往一个人当两三个人用，常常遇到的复杂业务用现有框架和技术无法解决，需要自己结合多个技术框架和知识点才能解决复杂的业务。
所以都是程序员，环境和平台造就了程序员代码风格和侧重点不同，但就工作态度和对技术的专注程度来说，大公司的程序员无疑是有更优异的条件来养成这些良好习惯的。作为程序员，一生还是应该去大厂体验不同的企业文化和更高素质的从业人员，自身的见识和深度也会有所不同。
单纯从技术上来说，大公司是小公司没法比的，
大公司系统要更加复杂，研究的东西更加深入。
比如高并发，大数据，
小公司没有那么大流量和数据量根本没办法研究，
大公司一个系统N台机器，
为了节省资源就要研究怎么使机器能力最大化，优化代码，优化逻辑。
小公司可能一两台机器就能支撑一个系统，只要没bug就能正常运行。
非技术层面的就看公司的业务能力了。
个人看法，
超详细的线程池使用解析
Java 中线程池是运用场景最多的并发框架，几乎所有需要异步或并发执行任务的程序都可以使用线程池。合理的使用线程池可以带来多个好处：
（1） 降低资源消耗 。通过重复利用已创建的线程降低线程在创建和销毁时造成的消耗。
（2） 提高响应速度 。当处理执行任务时，任务可以不需要等待线程的创建就能立刻执行。
（3） 提高线程的可管理性 。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一分配、调优和监控。
线程池的处理流程如上图所示
线程池中通过 ctl 字段来表示线程池中的当前状态，主池控制状态 ctl 是 AtomicInteger 类型，包装了两个概念字段：workerCount 和 runState，workerCount 表示有效线程数，runState 表示是否正在运行、正在关闭等状态。使用 ctl 字段表示两个概念，ctl 的前 3 位表示线程池状态，线程池中限制 workerCount 为(2^29 )-1（约 5 亿）个线程，而不是 (2^31)-1（20 亿）个线程。workerCount 是允许启动和不允许停止的工作程序的数量。该值可能与实际的活动线程数暂时不同，例如，当 ThreadFactory 在被询问时未能创建线程时，以及退出线程在终止前仍在执行记时。用户可见的池大小报告为工作集的当前大小。 runState 提供主要的生命周期控制，取值如下表所示：
runState 随着时间的推移而改变，在 awaitTermination() 方法中等待的线程将在状态达到 TERMINATED 时返回。状态的转换为：
RUNNING - SHUTDOWN 在调用 shutdown() 时，可能隐含在 finalize() 中
(RUNNING 或 SHUTDOWN)- STOP 在调用 shutdownNow() 时
SHUTDOWN - TIDYING 当队列和线程池都为空时
STOP - TIDYING 当线程池为空时
TIDYING - TERMINATED 当 terminate() 方法完成时
开发人员如果需要在线程池变为 TIDYING 状态时进行相应的处理，可以通过重载 terminated() 函数来实现。
结合上图说明线程池 ThreadPoolExecutor 执行流程，使用 execute() 方法提交任务到线程池中执行时分为4种场景：
（1）线程池中运行的线程数量小于 corePoolSize，创建新线程来执行任务。
（2）线程池中运行线程数量不小于 corePoolSize，将任务加入到阻塞队列 BlockingQueue。
（3）如果无法将任务加入到阻塞队列（队列已满），创建新的线程来处理任务（这里需要获取全局锁）。
（4）当创建新的线程数量使线程池中当前运行线程数量超过 maximumPoolSize，线程池中拒绝任务，调用 RejectedExecutionHandler.rejectedExecution() 方法处理。
源码分析：
线程池创建线程时，会将线程封装成工作线程 Worker，Worker 在执行完任务后，还会循环获取工作队列里的任务来执行。
创建线程池之前，首先要知道创建线程池中的核心参数：
corePoolSize （核心线程数大小）：当提交任务到线程池时，线程池会创建一个线程来执行任务，即使其他空闲的基本线程能够执行新任务也会创建线程，直到需要执行的任务数大于核心线程数时就不再创建。
runnableTaskQueue （任务队列）：用于保存等待执行任务的阻塞队列。一般选择以下几种：
ArrayBlockingQueue：基于数组的有界阻塞队列，按照 FIFO 原则对元素进行排序。
LinkedBlockingQueue：基于链表的阻塞队列，按照 FIFO 原则对元素进行排序。
SynchronousQueue：同步阻塞队列，也是不存储元素的阻塞队列。每一个插入操作必须要等到另一个 线程调用移除操作，否则插入操作一直处于阻塞状态。
PriorityBlockingQueue：优先阻塞队列，一个具有优先级的无限阻塞队列。
maximumPoolSize （最大线程数大小）：线程池允许创建的最大线程数，当队列已满，并且线程池中的线程数小于最大线程数，则线程池会创建新的线程执行任务。当使用无界队列时，此参数无用。
RejectedExecutionHandler （拒绝策略）：当任务队列和线程池都满了，说明线程池处于饱和状态，那么必须使用拒绝策略来处理新提交的任务。JDK 内置拒绝策略有以下 4 种：
AbortPolicy：直接抛出异常
CallerRunsPolicy：使用调用者所在的线程来执行任务
DiscardOldestPolicy：丢弃队列中最近的一个任务来执行当前任务
DiscardPolicy：直接丢弃不处理
可以根据应用场景来实现 RejectedExecutionHandler 接口自定义处理策略。
keepAliveTime （线程存活时间）：线程池的工作线程空闲后，保持存活的时间。
TimeUnit （存活时间单位）：可选单位DAYS（天）、HOURS（小时）、MINUTES（分钟）、MILLISECONDS（毫秒）、MICROSECONDS（微妙）、NANOSECONDS（纳秒）。
ThreadFactory （线程工厂）：可以通过线程工厂给创建出来的线程设置有意义的名字。
创建线程池主要分为两大类，第一种是通过 Executors 工厂类创建线程池，第二种是自定义创建线程池。根据《阿里java开发手册》中的规范，线程池不允许使用 Executors 去创建，原因是规避资源耗尽的风险。
创建一个单线程化的线程池
创建固定线程数的线程池
以上两种创建线程池方式使用链表阻塞队列来存放任务，实际场景中可能会堆积大量请求导致 OOM
创建可缓存线程池
允许创建的线程数量最大为 Integer.MAX_VALUE，当创建大量线程时会导致 CPU 处于重负载状态和 OOM 的发生
向线程池提交任务可以使用两个方法，分别为 execute() 和 submit()。
execute() 方法用于提交不需要返回值的任务，所以无法判断任务是否被线程池执行成功。execute() 方法中传入的是 Runnable 类的实例。
submit() 方法用于提交需要返回值的任务。线程池会返回一个 Future 类型的对象，通过 future 对象可以判断任务是否执行成功，并且可以通过 future 的 get() 方法来获取返回值。get() 方法会阻塞当前线程直到任务完成，使用 get(long timeout, TimeUnit unit)方法会阻塞当前线程一段时间后立即返回，这时候可能任务没有执行完。
可以通过调用线程池的 shutdown() 或shutdownNow() 方法来关闭线程池。他们的原理是遍历线程池中的工作线程，然后逐个调用 interrupt() 方法来中断线程，所以无法响应中断任务可能永远无法终止。
shutdown() 和 shutdownNow() 方法的区别在于 shutdownNow 方法首先将线程池的状态设置为 STOP，然后尝试停止正在执行或暂停任务的线程，并返回等待执行任务的列表，而 shutdown 只是将线程池的状态设置成 SHUTDOWN 状态，然后中断所有没有正在执行任务的线程。
线程池使用面临的核心的问题在于： 线程池的参数并不好配置 。一方面线程池的运行机制不是很好理解，配置合理需要强依赖开发人员的个人经验和知识；另一方面，线程池执行的情况和任务类型相关性较大，IO 密集型和 CPU 密集型的任务运行起来的情况差异非常大，这导致业界并没有一些成熟的经验策略帮助开发人员参考。
（1）以任务型为参考的简单评估：
假设线程池大小的设置(N 为 CPU 的个数)
如果纯计算的任务,多线程并不能带来性能提升，因为 CPU 处理能力是稀缺的资源，相反导致较多的线程切换的花销，此时建议线程数为 CPU 数量或+1；----为什么+1？因为可以防止 N 个线程中有一个线程意外中断或者退出，CPU 不会空闲等待。
如果是 IO 密集型应用, 则线程池大小设置为 2N+1. 线程数 = CPU 核数 目标 CPU 利用率 （1 + 平均等待时间 / 平均工作时间)
（2）以任务数为参考的理想状态评估：
1）默认值
2）如何设置 * 需要根据相关值来决定 - tasks ：每秒的任务数，假设为500~1000 - taskCost：每个任务花费时间，假设为0.1s - responsetime：系统允许容忍的最大响应时间，假设为1s
以上都为理想值，实际情况下要根据机器性能来决定。如果在未达到最大线程数的情况机器 cpu load 已经满了，则需要通过升级硬件和优化代码，降低 taskCost 来处理。
（仅为简单的理想状态的评估，可作为线程池参数设置的一个参考）
与主业务无直接数据依赖的从业务可以使用异步线程池来处理，在项目初始化时创建线程池并交给将从业务中的任务提交给异步线程池执行能够缩短响应时间。
严禁在业务代码中起线程！！！
当任务需要按照指定顺序(FIFO, LIFO, 优先级)执行时，推荐创建使用单线程化的线程池。
本文章主要说明了线程池的执行原理和创建方式以及推荐线程池参数设置和一般使用场景。在开发中，开发人员需要根据业务来合理的创建和使用线程池达到降低资源消耗，提高响应速度的目的。
原文链接：
阿里不推荐java线程池的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于Java常见的线程池、阿里不推荐java线程池的信息别忘了在本站进行查找喔。