java线程学习总结1(java thread培训总结1)1．线程中一些基本术语和概念 (2)1.1线程的几个状态 (2)1.2 Daemon线程 (2)1.3锁的定义 (2)1.4死锁 (2)1.5.Java对象关于锁的几个方法 (3)1.6锁对象(实例方法的锁) (3)1.7类锁 (4)1.8.线程安全方法与线程不安全方法 (4)1.9类锁和实例锁混合使用 (4)1.10锁的粒度问题 (4)1.11.读写锁 (5)1.12 volatile (5)2．线程之间的通讯 (5)2.1屏障 (6)2.2.锁工具类 (6)2.3.条件变量 (6)3. Java线程调度 (7)3.1 Java优先级 (7)3.2. 绿色线程 (7)3.3 本地线程 (7)3.4 Windows本地线程 (7)3.5线程优先级倒置与继承 (8)3.6循环调度 (8)4.线程池 (8)5工作队列 (9)6.参考资料 (10)1．线程中一些基本术语和概念1.1线程的几个状态初始化状态就绪状态运行状态阻塞状态终止状态1.2 Daemon线程Daemon线程区别一般线程之处是：主程序一旦结束，Daemon线程就会结束。
1.3锁的定义为了协调多个并发运行的线程使用共享资源才引入了锁的概念。
1.4死锁任何多线程应用程序都有死锁风险。
当一组线程中的每一个都在等待一个只有该组中另一个线程才能引起的事件时，我们就说这组线程死锁了。
换一个说法就是一组线程中的每一个成员都在等待别的成员占有的资源时候，就可以说这组线程进入了死锁。
死锁的最简单情形是：线程 A 持有对象X 的独占锁，并且在等待对象Y 的锁，而线程 B 持有对象Y 的独占锁，却在等待对象X 的锁。
除非有某种方法来打破对锁的等待（Java 锁定不支持这种方法），否则死锁的线程将永远等下去。
1.5.Java对象关于锁的几个方法1.5.1 wait方法wait方法是java根对象Object含有的方法，表示等待获取某个锁。
在wait 方法进入前，会释放相应的锁，在wait方法返回时，会再次获得某个锁。
如果wait()方法不带有参数，那只有当持有该对象锁的其他线程调用了notify 或者notifyAll方法，才有可能再次获得该对象的锁。
如果wait()方法带有参数，比如：wait(10)，那当持有该对象锁的其他线程调用了notify或者notifyAll方法，或者指定时间已经过去了，才有可能再次获得该对象的锁。
参考thread.lock.SleepAndWait1.5.2 notify/notifyAll方法这里我就不再说明了。
哈哈，偷点懒。
1.5.3 yield方法yield()会自动放弃CPU，有时比sleep更能提升性能。
1.6锁对象(实例方法的锁)在同步代码块中使用锁的时候，担当锁的对象可以是这个代码所在对象本身或者一个单独的对象担任，但是一定要确保锁对象不能为空。
如果对一个null 对象加锁，会产生异常的。
原则上不要选择一个可能在锁的作用域中会改变值的实例变量作为锁对象。
锁对象,一种是对象自己担任，一种是定义一个普通的对象作为private property来担任，另外一种是建立一个新的类，然后用该类的实例来担任。
参考 :eSelfAsLock，使用对象自己做锁对象eObjAsLock 使用一个实例对象作锁对象eAFinalObjAsLock使用常量对象作为一个锁对象1.7类锁实例方法存在同步的问题，同样，类方法也存在需要同步的情形。
一般类方法的类锁是一个static object来担任的。
当然也可以采用类本身的类对象来作为类锁。
一个类的实例方法可以获得该类实例锁，还可以尝试去访问类方法，包含类同步方法，去获得类锁。
一个类的类方法，可以尝试获得类锁，但是不可以尝试直接获得实例锁。
需要先生成一个实例，然后在申请获得这个实例的实例锁。
参考eStaticObjAsStaticLock 使用类的属性对象作为类锁。
eClassAsStaticLock使用类的类对象作为类锁1.8.线程安全方法与线程不安全方法如果一个对象的所有的public方法都是同步方法，也就是说是public方法是线程安全的，那该对象的private方法，在不考虑继承的情况下，可以设置为不是线程安全的方法。
参考 thread.lock.SynMethrodAndNotSynMethrod1.9类锁和实例锁混合使用在实例方法中混合使用类锁和实例锁；可以根据前面说的那样使用实例锁和类锁。
在类方法中混合使用类锁和实例锁，可以根据前面说的那样使用类锁，为了使用实例锁，先得生成一个实例，然后实例锁。
参考 thread.lock.StaticLockAndObjLock1.10锁的粒度问题。
为了解决对象锁的粒度过粗，会导死锁出现的可能性加大，锁的粒度过细，会程序开发维护的工作加大。
对于锁的粒度大小，这完全要根据实际开发需要来考虑，很难有一个统一的标准。
1.11.读写锁一个读写锁支持多个线程同时访问一个对象，但是在同一时刻只有一个线程可以修改此对象，并且在访问进行时不能修改。
有2种调度策略，一种是读锁优先，另外就是写锁优先。
参考 thread.lock.ReadWriteLock1.12 volatile在Java中设置变量值的操作，除了long和double类型的变量外都是原子操作，也就是说，对于变量值的简单读写操作没有必要进行同步。
这在JVM 1.2之前，Java的内存模型实现总是从主存读取变量，是不需要进行特别的注意的。
而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变得非常重要。
在当前的Java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。
这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。
要解决这个问题，只需要像在本程序中的这样，把该变量声明为volatile（不稳定的）即可，这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。
一般说来，多任务环境下各任务间共享的标志都应该加volatile修饰。
2．线程之间的通讯在其他语言中，线程之间可以通过消息队列，共享内存，管道等方式来实现线程之间的通讯，但是java中可以不采用这样方式，关注的是线程之间的同步。
只要保证相关方法运行的线程安全，信息共享是自然就可以显现了。
2.1屏障屏障就是这样的一个等待点: 一组线程在这一点被同步，这些线程合并各自的结果或者运行到整体任务的下一阶段。
参考：thread.lock. BarrierUseExamplethread.lock.Barrier2.2.锁工具类提供对线程锁的获取，释放功能。
展示了锁的获取释放过程。
可以作为一个工具类来使用。
参考：thread.lock. BusyFlag2.3.条件变量条件变量是POSIX线程模型提供的一种同步类型，和java中的等待通知机制类似。
虽然java中已经有了等待通知机制，但是为了减少在notify/notifyAll方法中线程调度的开销，把一些不需要激活的线程屏蔽出去，引入了条件变量。
Java中2个（多个）条件变量可以是同一个互斥体（锁对象）。
参考：thread.lock.CondVar 条件变量类常见的应用情形：一个锁控制多个信号通道（例如：多个变量），虽然可以采用简单java 等待通知机制，但是线程调度效率不高，而且线程可读性也不是太好，这时候可以采用创建一个锁对象(BusyFlag实例)，同时使用这个BusyFlag实例来创建多个条件变量(CondVar 实例)。
经常使用到CondVar类的地方是缓冲区管理，比如：管道操作之类的。
先创建一个BusyFlag实例，然后创建CondVar 实例，用这个条件变量描述缓冲区是否为空，另外创建CondVar 实例作条件变量述缓冲区是否满。
现实中，马路的红绿灯，就可以采用条件变量来描述。
3. Java线程调度3.1 Java优先级java的优先级别共有10种，加上虚拟机自己使用的优先级别=0这种，总共11种。
大多数情况来说，java线程的优先级设置越高（最高=10），那线程越优先运行。
3.2. 绿色线程线程运行在虚拟机内，操作系统根本不知道这类线程的存在。
线程是由虚拟机调度的。
3.3 本地线程线程是由运行虚拟机的操作系统完成的。
3.4 Windows本地线程操作系统，完全能够看得到虚拟机内的每一个线程，同时虚拟机的线程和操作系统的线程是一一对应的。
Java的线程调度室由操作系统底层线程决定的。
在win32平台下，windows线程只有6个优先级别。
和java线程优先级别对应如下：3.5线程优先级倒置与继承如果一个线程持有锁(假设该线程名字=ThreadA,优先级别=5)，另外一个线程(假设该线程名字=ThreadB,优先级别=7),现在该线程(ThreadA)处于运行状态，但是线程ThreadB申请需要持有ThreadA所获得的锁，这时候，为了避免死锁，线程A提高其运行的优先级别（提高到ThreadB的优先级别=7）,而线程ThreadB 为了等待获得锁，降低线程优先级别(降低到ThreadA原来的优先级别=5).上述的这种情况，对于ThreadA,继承了ThreadB的优先级别，这成为优先级别的继承；对于ThreadB暂时降低了优先级别，成为优先级别的倒置。
当然，一旦线程ThreadA持有的锁释放了，其优先级别也会回到原来的优先级别（优先级别=5）。
线程ThreadB获得了相应的锁，那优先级别也会恢复到与原来的值(优先级别=7)。
3.6循环调度具有同样优先级的线程相互抢占成为循环调度。
4.线程池创建一个线程也是需要一定代价的,为了降低这个代价，采用了和普通对象池的思想建立线程池，以供系统使用。
线程消耗包括内存和其它系统资源在内的大量资源。
除了Thread对象所需的内存之外，每个线程都需要两个可能很大的执行调用堆栈。
除此以外，JVM 可能会为每个Java 线程创建一个本机线程，这些本机线程将消耗额外的系统资源。
最后，虽然线程之间切换的调度开销很小，但如果有很多线程，环境切换也可能严重地影响程序的性能。
使用线程池的方式是，先建立对象池，然后申请使用线程，程序线程运行，运行完毕，把线程返回线程池。
使用线程池的风险：同步错误和死锁，与池有关的死锁、资源不足和线程泄漏。
大家有空可以研究一下tomcat的线程池实现原理思想。
实际上是tomcat已经在从线程池的使用线程时候加上了事件处理机制。
个人认为，线程池之类的实现，一般不要自己实现，因为自己实现主要是稳定性等方面可能作的不够好。