线程：
关于生命周期的五种状态是要清楚的，知道线程的生命周期很重要， new->runnable->running->blocked->dead
新建状态（New）：当线程对象对创建后，即进入了新建状态，如：Thread t = new MyThread();
就绪状态（Runnable）：当调用线程对象的start()方法（t.start();），线程即进入就绪状态。处于就绪状态的线程，只是说明此线程已经做好了准备，随时等待CPU调度执行，并不是说执行了t.start()此线程立即就会执行；
运行状态（Running）：当CPU开始调度处于就绪状态的线程时，此时线程才得以真正执行，即进入到运行状态。注：就 绪状态是进入到运行状态的唯一入口，也就是说，线程要想进入运行状态执行，首先必须处于就绪状态中；
死亡状态（Dead）：线程执行完了或者因异常退出了run()方法，该线程结束生命周期。
阻塞最重要，消息类处理，深入理解阻塞，至关重要。
阻塞状态（Blocked）：处于运行状态中的线程由于某种原因，暂时放弃对CPU的使用权，停止执行，此时进入阻塞状态，直到其进入到就绪状态，才有机会再次被CPU调用以进入到运行状态。根据阻塞产生的原因不同，阻塞状态又可以分为三种：
1.等待阻塞：运行状态中的线程执行wait()方法，使本线程进入到等待阻塞状态；
2.同步阻塞 -- 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态；
3.其他阻塞 -- 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。
线程创建：
老一点的两种方式，用extend Thread Or implements Runnable，Runable也是集成Thread的，线程需要处理的业务就在public void run()里实现。
最后启动，需要注意的是，runnable还是要给Thread来调起，如下代码：
Thread:
Thread1 t1 = new Thread1("t1");
Thread1 t2 = new Thread1("t2");
t1.start();
t2.start();
Runnable:
RunnableTest r1 = new RunnableTest("t1");
Thread t1 = new Thread(r1);
RunnableTest r2 = new RunnableTest("t2");
Thread t2 = new Thread(r2);
t1.start();
t2.start();
现在有用一种新的方式了 Callable和Future，在这里一起学习下
Callable接口类似于Runnable，但是Runnable里执行任务比较封闭，不会返回线程结果，并且无法抛出返回结果的异常，而Callable功能更强大一些，被线程执行后，可以返回值，这个返回值可以被Future拿到，也就是说，Future可以拿到异步执行任务的返回值。
执行结果：加上时间以后，比较清楚了，程序的最后，是等线程里结束了，全部结束。 会节约很多时间。
FutureTask实现了两个接口，Runnable和Future，所以它既可以作为Runnable被线程执行，又可以作为Future得到Callable的返回值，那么这个组合的使用有什么好处呢？假设有一个很耗时的返回值需要计算，并且这个返回值不是立刻需要的话，那么就可以使用这个组合，用另一个线程去计算返回值，而当前线程在使用这个返回值之前可以做其它的操作，等到需要这个返回值时，再通过Future得到，岂不美哉！这里有一个Future模式的介绍：http://openhome.cc/Gossip/DesignPattern/FuturePattern.htm。
下面来看另一种方式使用Callable和Future，通过ExecutorService的submit方法执行Callable，并返回Future，代码如下
执行结果
代码是不是简化了很多，不用new Thread了，ExecutorService继承自Executor，它的目的是为我们管理Thread对象，从而简化并发编程，Executor使我们无需显示的去管理线程的生命周期，是JDK 5之后启动任务的首选方式。
执行多个带返回值的任务，并取得多个返回值，代码如下：
其实也可以不使用CompletionService，可以先创建一个装Future类型的集合，用Executor提交的任务返回值添加到集合中，最后遍历集合取出数据，代码略。更新于2016-02-05，评论中就这个说法引发了讨论，其实是我没有讲清楚，抱歉。这里再阐述一下：提交到CompletionService中的Future是按照完成的顺序排列的，这种做法中Future是按照添加的顺序排列的。所以这两种方式的区别就像评论中fishjam所描述的那样。
转自博客http://blog.csdn.net/ghsau/article/details/7451464
-------------------------------------------------
使用Callable和Future接口创建线程。具体是创建Callable接口的实现类，并实现clall()方法。并使用FutureTask类来包装Callable实现类的对象，且以此FutureTask对象作为Thread对象的target来创建线程。
callable和future应该还有多种形式，这个以后用到再具体研究吧。
创建方式说完，继续回到线程阻塞吧，这是一个大块，需要好好理解
--------------------以下是线程阻塞-----------------------
http://blog.csdn.net/seelye/article/details/7656934
阻塞指的是暂停一个线程的执行以等待某个条件发生（如某资源就绪），学过操作系统的同学对它一定已经很熟悉了。Java 提供了大量方法来支持阻塞，下面让我们逐一分析。
1. sleep() 方法：sleep() 允许 指定以毫秒为单位的一段时间作为参数，它使得线程在指定的时间内进入阻塞状态，不能得到CPU 时间，指定的时间一过，线程重新进入可执行状态。
典型地，sleep() 被用在等待某个资源就绪的情形：测试发现条件不满足后，让线程阻塞一段时间后重新测试，直到条件满足为止。
2. suspend() 和 resume() 方法：两个方法配套使用，suspend()使得线程进入阻塞状态，并且不会自动恢复，必须其对应的resume() 被调用，才能使得线程重新进入可执行状态。典型地，suspend() 和 resume() 被用在等待另一个线程产生的结果的情形：测试发现结果还没有产生后，让线程阻塞，另一个线程产生了结果后，调用 resume() 使其恢复。
3. yield() 方法：yield() 使得线程放弃当前分得的 CPU 时间，但是不使线程阻塞，即线程仍处于可执行状态，随时可能再次分得 CPU 时间。调用 yield() 的效果等价于调度程序认为该线程已执行了足够的时间从而转到另一个线程。
4. wait() 和 notify() 方法：两个方法配套使用，wait() 使得线程进入阻塞状态，它有两种形式，一种允许 指定以毫秒为单位的一段时间作为参数，另一种没有参数，前者当对应的 notify() 被调用或者超出指定时间时线程重新进入可执行状态，后者则必须对应的 notify() 被调用。
初看起来它们与 suspend() 和 resume() 方法对没有什么分别，但是事实上它们是截然不同的。区别的核心在于，前面叙述的所有方法，阻塞时都不会释放占用的锁（如果占用了的话），而这一对方法则相反。wait()会释放对象锁
上述的核心区别导致了一系列的细节上的区别。
首先，前面叙述的所有方法都隶属于 Thread 类，但是这一对却直接隶属于 Object 类，也就是说，所有对象都拥有这一对方法。初看起来这十分不可思议，但是实际上却是很自然的，因为这一对方法阻塞时要释放占用的锁，而锁是任何对象都具有的，调用任意对象的 wait() 方法导致线程阻塞，并且该对象上的锁被释放。而调用 任意对象的notify()方法则导致因调用该对象的 wait() 方法而阻塞的线程中随机选择的一个解除阻塞（但要等到获得锁后才真正可执行）。
其次，前面叙述的所有方法都可在任何位置调用，但是这一对方法却必须在 synchronized 方法或块中调用，理由也很简单，只有在synchronized 方法或块中当前线程才占有锁，才有锁可以释放。同样的道理，调用这一对方法的对象上的锁必须为当前线程所拥有，这样才有锁可以释放。因此，这一对方法调用必须放置在这样的 synchronized 方法或块中，该方法或块的上锁对象就是调用这一对方法的对象。若不满足这一条件，则程序虽然仍能编译，但在运行时会出现IllegalMonitorStateException 异常。
wait() 和 notify() 方法的上述特性决定了它们经常和synchronized 方法或块一起使用，将它们和操作系统的进程间通信机制作一个比较就会发现它们的相似性：synchronized方法或块提供了类似于操作系统原语的功能，它们的执行不会受到多线程机制的干扰，而这一对方法则相当于 block 和wakeup 原语（这一对方法均声明为 synchronized）。它们的结合使得我们可以实现操作系统上一系列精妙的进程间通信的算法（如信号量算法），并用于解决各种复杂的线程间通信问题。
关于 wait() 和 notify() 方法最后再说明两点：
第一：调用 notify() 方法解除阻塞的线程，是从因调用该对象的 wait() 方法的线程中随机选取的，我们无法预料哪一个线程将会被选择，所以编程时要特别小心，避免因这种不确定性而产生问题。
第二：除了 notify()，还有一个方法 notifyAll() 也可起到类似作用，唯一的区别在于，调用 notifyAll() 方法将把因调用该对象的 wait() 方法而阻塞的所有线程一次性全部解除阻塞。当然，只有获得锁的那一个线程才能进入可执行状态。
谈到阻塞，就不能不谈一谈死锁，略一分析就能发现，suspend() 方法和不指定超时期限的 wait() 方法的调用都可能产生死锁。遗憾的是，Java 并不在语言级别上支持死锁的避免，我们在编程中必须小心地避免死锁。
以上我们对 Java 中实现线程阻塞的各种方法作了一番分析，我们重点分析了 wait() 和 notify() 方法，因为它们的功能最强大，使用也最灵活，但是这也导致了它们的效率较低，较容易出错。实际使用中我们应该灵活使用各种方法，以便更好地达到我们的目的。
-----------------------------------------------
http://blog.csdn.net/hll814/article/details/50816268
多线程的应用：
通俗的解释一下多线程先：
多线程用于堆积处理，就像一个大土堆，一个推土机很慢，那么10个推土机一起来处理，当然速度就快了，不过由于位置的限制，如果20个推土机，那么推土机之间会产生相互的避让，相互摩擦，相互拥挤，反而不如10个处理的好，所以，多线程处理，线程数要开的恰当，就可以提高效率。
多线程使用的目的：
1、 吞吐量：做WEB，容器帮你做了多线程，但是它只能帮你做请求层面的，简单的说，就是一个请求一个线程(如struts2，是多线程的，每个客户端请求创建一个实例，保证线程安全)，或多个请求一个线程，如果是单线程，那只能是处理一个用户的请求
2、 伸缩性：通过增加CPU核数来提升性能。
多线程在程序中的作用：
1、提高前端请求的响应速度。当我们执行一个比较耗时的方法时，http请求得不到响应甚至会超时，这时如果业务上允许数据的延迟，我们可以使用多线程来进行处理比较耗时的方法。这样前端发送了请求，后端令开启了一个线程去处理任务，就不会阻塞主线程了。
2、减清服务器的压力。包括我们的web容器，如tomcat、jetty等，还有数据库服务器等。因为我们使用了多线程，并且线程池大小有限制，如30，那么同时请求数据库的链接就限制为30了，也就是说能够同时执行方法的线程只有30个，其余的任务都放在我们线程的任务队列了，这样数据库就不会被突然上来的请求给压垮了。当然对于缓解数据库压力来说，更建议使用消息队列，使用消息队列我们可以攒数据进行批量提交，而仅仅使用多线程，则不好实现攒数据的过程。
3、提高处理能力，增加性能，充分利用服务器资源。如我们要将三个表里的数据加载到缓存，最简单的我们一个表开启一个线程，共用三个线程去加载缓存则比用一个线程去挨着遍历三个表的数据高效的多。
多线程的使场景：
1、 常见的浏览器、Web服务(现在写的web是中间件帮你完成了线程的控制)，web处理请求，各种专用服务器(如游戏服务器)
2、 servlet多线程，多连接
3、 FTP下载，多线程操作文件
4、 数据库用到的多线程
5、 分布式计算
6、 tomcat，tomcat内部采用多线程，上百个客户端访问同一个WEB应用，tomcat接入后就是把后续的处理扔给一个新的线程来处理，这个新的线程最后调用我们的servlet程序，比如doGet或者dpPost方法
7、 后台任务：如定时向大量(100W以上)的用户发送邮件；定期更新配置文件、任务调度(如quartz)，一些监控用于定期信息采集
8、 自动作业处理：比如定期备份日志、定期备份数据库
9、 异步处理：如发微博、记录日志
10、 页面异步处理：比如大批量数据的核对工作(有10万个手机号码，核对哪些是已有用户)
11、 数据库的数据分析(待分析的数据太多)，数据迁移
12、 多步骤的任务处理，可根据步骤特征选用不同个数和特征的线程来协作处理，多任务的分割，由一个主线程分割给多个线程完成
13、 desktop应用开发，一个费时的计算开个线程，前台加个进度条显示
14、 swing编程
举一个小栗子：
一个文本文件有100M，全是字符串，我要执行切分字符串，每达到N长度便执行切腹，最后求切分完成的字符串的集合
单线程处理：读取文本文件数据，扫描全部数据，一个一个的切分，最后消耗时间=文件传输时间(文本数据加载到内存)+切分过程消耗
多线程处理：
专门设置一个线程执行加载数据的操作，此时，如果加载的数据达到一个设定值，启动一个切线程处理，如此继续，多个切分字符串的线程能够并发执行，CPU的利用率提高了(文件传输的过程中没有占用处理器，而可以将加载的部分数据分配给切分线程，占用处理器来执行任务)
总结：
单线程处理，文件加载的过程中，处理器一直空闲，但也被加入到总执行时间之内，串行执行切分总时间，等于每切分一个时间*切分后字符串的个数，执行程序，估计等几分钟能处理完就不错了
多线程处理，文件加载过程与拆分过程，拆分过程与拆分过程，都存在并发——文件加载的过程中就执行了切分任务，切分任务执行过程中多线程并行处理，总消耗时间能比单线程提高很多，甚至几个数量级都不止。
------------应用场景下面这篇说的挺逗
https://www.cnblogs.com/kenshinobiy/p/4671314.html
多线程使用的主要目的在于：
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都不到。
伪代码：
public class MyServlet extends Servlet{
private static Map<String, String> fileName2Data = new HashMap<String, String>();
private void processFile3(String fName){
String data = fileName2Data.get(fName);
if(data==null){
data = readFromFile(fName); //耗时28ms
fileName2Data.put(fName, data);
}
//process with data
}
}
看起来好像还不错，建立一个文件名和文件数据的映射。如果读取一个map中已经存在的数据，那么就不不用读取文件了。
可是问题在于，Servlet是并发，上面会导致一个很严重的问题，死循环。因为，HashMap在并发修改的时候，可能是导致循环链表的构成！！！（具体你可以自行阅读HashMap源码）如果你没接触过多线程，可能到时候发现服务器没请求也巨卡，也不知道什么情况！
好的，那就用ConcurrentHashMap，正如他的名字一样，他是一个线程安全的HashMap，这样能轻松解决问题。
public class MyServlet extends Servlet{
private static ConcurrentHashMap<String, String> fileName2Data = new ConcurrentHashMap<String, String>();
private void processFile3(String fName){
String data = fileName2Data.get(fName);
if(data==null){
data = readFromFile(fName); //耗时28ms
fileName2Data.put(fName, data);
}
//process with data
}
}
| 这样真的解决问题了吗，这样虽然只要有用户访问过文件a，那另一个用户想访问文件a，也会从fileName2Data中拿数据，然后也不会引起死循环。 public class MyServlet extends Servlet{
private static ConcurrentHashMap<String, String> fileName2Data = new ConcurrentHashMap<String, String>();
private void processFile3(String fName){
String data = fileName2Data.get(fName);
//“偶然”-- 1000个线程同时到这里，同时发现data为null
if(data==null){
data = readFromFile(fName); //耗时28ms
fileName2Data.put(fName, data);
}
//process with data
}
} 上面注释的“偶然”，这是完全有可能的，因此，这样做还是有问题。 |
public class MyServlet extends Servlet{
private static ConcurrentHashMap<String, FutureTask> fileName2Data = new ConcurrentHashMap<String, FutureTask>();
private static ExecutorService exec = Executors.newCacheThreadPool();
private void processFile3(String fName){
FutureTask data = fileName2Data.get(fName);
//“偶然”-- 1000个线程同时到这里，同时发现data为null
if(data==null){
data = newFutureTask(fName);
FutureTask old = fileName2Data.putIfAbsent(fName, data);
if(old==null){
data = old;
}else{
exec.execute(data);
}
}
String d = data.get();
//process with data
}
private FutureTask newFutureTask(final String file){
return new FutureTask(new Callable<String>(){
public String call(){
return readFromFile(file);
}
private String readFromFile(String file){return "";}
}
}
}
以上所有代码都是直接在bbs打出来的，不保证可以直接运行。
多线程最多的场景：web服务器本身；各种专用服务器（如游戏服务器）；
多线程的常见应用场景：
1、后台任务，例如：定时向大量（100w以上）的用户发送邮件；
2、异步处理，例如：发微博、记录日志等；
3、分布式计算
--------------------------
线程安全：
扫一扫
3174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
