博客分类：
公司内部同事分享的一篇文章
周末看到一个用jstack查看死锁的例子。昨天晚上总结了一下jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令。供大家参考
1．Jstack
1.1&& jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。如下图所示
注：这个和thread dump是同样的结果。但是thread dump是用kill -3 pid命令，还是服务器上面少用kill为妙
1.2&& 命名行格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
最常用的还是jstack& pid
1.3&& 在thread dump中，要留意下面几种状态
死锁，Deadlock（重点关注）
等待资源，Waiting on condition（重点关注）
o& 等待获取监视器，Waiting on monitor entry（重点关注）
阻塞，Blocked（重点关注）
o& 执行中，Runnable
o& 暂停，Suspended
o& 对象等待中，Object.wait() 或 TIMED_WAITING
o& 停止，Parked
下面有详细的例子讲这种分析，大家参考原著
http://www.cnblogs.com/zhengyun_ustc/archive//dumpanalysis.html
1.4&& 在thread dump中，有几种线程的定义如下
线程名称
解释说明
Attach Listener JVM Attach Listener 线程是负责接收到外部的命令，而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求jvm给我们一些反馈信息，如：java -version、jmap、jstack等等。 如果该线程在jvm启动的时候没有初始化，那么，则会在用户第一次执行jvm命令时，得到启动。
Signal Dispatcher JVM 前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令，当命令接收成功后，会交给signal dispather 线程去进行分发到各个不同的模块处理命令，并且返回处理结果。 signal dispather线程也是在第一次接收外部jvm命令时，进行初始化工作。
CompilerThread0 JVM 用来调用JITing，实时编译装卸class 。 通常，jvm会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，例如：CompilerThread1
Concurrent Mark-Sweep GC Thread JVM 并发标记清除垃圾回收器（就是通常所说的CMS GC）线程， 该线程主要针对于老年代垃圾回收。ps：启用该垃圾回收器，需要在jvm启动参数中加上： -XX:+UseConcMarkSweepGC
DestroyJavaVM JVM 执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。&& JVM在 Jboss 服务器启动之后，就会唤起DestroyJavaVM线程，处于等待状态，等待其它线程（java线程和native线程）退出时通知它卸载JVM。线程退出时，都会判断自己当前是否是整个JVM中最后一个非deamon线程，如果是，则通知DestroyJavaVM 线程卸载JVM。
ps：
扩展一下：
1.如果线程退出时判断自己不为最后一个非deamon线程，那么调用thread-&exit(false) ，并在其中抛出thread_end事件，jvm不退出。
2.如果线程退出时判断自己为最后一个非deamon线程，那么调用before_exit() 方法，抛出两个事件：& 事件1：thread_end 线程结束事件、事件2：VM的death事件。
&&& 然后调用thread-&exit(true) 方法，接下来把线程从active list卸下，删除线程等等一系列工作执行完成后，则通知正在等待的DestroyJavaVM 线程执行卸载JVM操作。
ContainerBackgroundProcessor 线程 JBOSS 它是一个守护线程, 在jboss服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除.
参考：http://liudeh-009.iteye.com/blog/1584876
Dispatcher-Thread-3& 线程 Log4j &&&&& Log4j具有异步打印日志的功能，需要异步打印日志的Appender都需要注册到 AsyncAppender对象里面去，由AsyncAppender进行监听，决定何时触发日志打印操作。 AsyncAppender如果监听到它管辖范围内的Appender有打印日志的操作，则给这个Appender生成一个相应的event，并将该event保存在一个buffuer区域内。& Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了，如果已经满了，则将缓存区内的所有event分发到Appender容器里面去，那些注册上来的Appender收到自己的event后，则开始处理自己的日志打印工作。 Dispatcher-Thread-3线程是一个守护线程。
Finalizer线程 JVM 这个线程也是在main线程之后创建的，其优先级为10，主要用于在垃圾收集前，调用对象的finalize()方法；关于Finalizer线程的几点：
1) 只有当开始一轮垃圾收集时，才会开始调用finalize()方法；因此并不是所有对象的finalize()方法都会被执行；
2) 该线程也是daemon线程，因此如果虚拟机中没有其他非daemon线程，不管该线程有没有执行完finalize()方法，JVM也会退出；
3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象（Reference的实现），并放入ReferenceQueue，由Finalizer线程来处理；最后将该Finalizer对象的引用置为null，由垃圾收集器来回收；
4) JVM为什么要单独用一个线程来执行finalize()方法呢？如果JVM的垃圾收集线程自己来做，很有可能由于在finalize()方法中误操作导致GC线程停止或不可控，这对GC线程来说是一种灾难；
Gang worker#0 JVM JVM 用于做新生代垃圾回收（monir gc）的一个线程。#号后面是线程编号，例如：Gang worker#1
GC Daemon JVM GC Daemon 线程是JVM为RMI提供远程分布式GC使用的，GC Daemon线程里面会主动调用System.gc()方法，对服务器进行Full GC。 其初衷是当 RMI 服务器返回一个对象到其客户机（远程方法的调用方）时，其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时，或者如果引用的“租借”过期并且没有更新，服务器将垃圾回收远程对象。
不过，我们现在jvm启动参数都加上了-XX:+DisableExplicitGC配置，所以，这个线程只有打酱油的份了。
IdleRemover JBOSS Jboss连接池有一个最小值， 该线程每过一段时间都会被Jboss唤起，用于检查和销毁连接池中空闲和无效的连接，直到剩余的连接数小于等于它的最小值。
Java2D Disposer JVM &&&&&&&&& 这个线程主要服务于awt的各个组件。 说起该线程的主要工作职责前，需要先介绍一下Disposer类是干嘛的。 Disposer提供一个addRecord方法。 如果你想在一个对象被销毁前再做一些善后工作，那么，你可以调用Disposer#addRecord方法，将这个对象和一个自定义的DisposerRecord接口实现类，一起传入进去，进行注册。&
&&&&&&&&& Disposer类会唤起“Java2D Disposer”线程，该线程会扫描已注册的这些对象是否要被回收了，如果是，则调用该对象对应的DisposerRecord实现类里面的dispose方法。
&&&&&&&&& Disposer实际上不限于在awt应用场景，只是awt里面的很多组件需要访问很多操作系统资源，所以，这些组件在被回收时，需要先释放这些资源。
InsttoolCacheScheduler_
QuartzSchedulerThread Quartz &&&&&&& InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主线程，它主要负责实时的获取下一个时间点要触发的触发器，然后执行触发器相关联的作业 。
&&&&&&&& 原理大致如下：
&&&&&&&& Spring和Quartz结合使用的场景下，Spring IOC容器初始化时会创建并初始化Quartz线程池（TreadPool），并启动它。刚启动时线程池中每个线程都处于等待状态，等待外界给他分配Runnable（持有作业对象的线程）。
&&&&&&&& 继而接着初始化并启动Quartz的主线程（InsttoolCacheScheduler_QuartzSchedulerThread），该线程自启动后就会处于等待状态。等待外界给出工作信号之后，该主线程的run方法才实质上开始工作。run中会获取JobStore中下一次要触发的作业，拿到之后会一直等待到该作业的真正触发时间，然后将该作业包装成一个JobRunShell对象（该对象实现了Runnable接口，其实看是上面TreadPool中等待外界分配给他的Runnable），然后将刚创建的JobRunShell交给线程池，由线程池负责执行作业。
线程池收到Runnable后，从线程池一个线程启动Runnable，反射调用JobRunShell中的run方法，run方法执行完成之后， TreadPool将该线程回收至空闲线程中。
InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现，它主要负责分配线程资源去执行
InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务（也就是JobRunShell）。
JBossLifeThread Jboss &&&&&&& Jboss主线程启动成功，应用程序部署完毕之后将JBossLifeThread线程实例化并且start，JBossLifeThread线程启动成功之后就处于等待状态，以保持Jboss Java进程处于存活中。& 所得比较通俗一点，就是Jboss启动流程执行完毕之后，为什么没有结束？ 就是因为有这个线程hold主了它。 牛b吧～～
JBoss System Threads(1)-1 Jboss & 该线程是一个socket服务，默认端口号为： 1099。 主要用于接收外部naming service（Jboss& JNDI）请求。
JCA PoolFiller Jboss &&& 该线程主要为JBoss内部提供连接池的托管。& 简单介绍一下工作原理 ：
&&& Jboss内部凡是有远程连接需求的类，都需要实现ManagedConnectionFactory接口，例如需要做JDBC连接的
XAManagedConnectionFactory对象，就实现了该接口。然后将XAManagedConnectionFactory对象，还有其它信息一起包装到InternalManagedConnectionPool对象里面，接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。&& JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象，如果有的话，则调用该对象的fillToMin方法， 触发它去创建相应的远程连接，并且将这个连接维护到它相应的连接池里面去。
JDWP Event Helper Thread JVM &&&&&&&&&&
JDWP是通讯交互协议，它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码，保证了前端和后端的JVMTI和JDI的通信通畅。& 该线程主要负责将JDI事件映射成JVMTI信号，以达到调试过程中操作JVM的目的。&&
JDWP Transport Listener: dt_socket JVM
该线程是一个Java Debugger的监听器线程，负责受理客户端的debug请求。 通常我们习惯将它的监听端口设置为8787。
Low Memory Detector JVM 这个线程是负责对可使用内存进行检测，如果发现可用内存低，分配新的内存空间。
process reaper JVM &&& 该线程负责去执行一个 OS 命令行的操作。
Reference Handler JVM &&&&&&& JVM在创建main线程后就创建Reference Handler线程，其优先级最高，为10，它主要用于处理引用对象本身（软引用、弱引用、虚引用）的垃圾回收问题 。
Surrogate Locker Thread (CMS) JVM &&&&&&&&& 这个线程主要用于配合CMS垃圾回收器使用，它是一个守护线程，其主要负责处理GC过程中，Java层的Reference（指软引用、弱引用等等）与jvm 内部层面的对象状态同步。 这里对它们的实现稍微做一下介绍：这里拿 WeakHashMap做例子，将一些关键点先列出来（我们后面会将这些关键点全部串起来）：
1.& 我们知道HashMap用Entry[]数组来存储数据的，WeakHashMap也不例外, 内部有一个Entry[]数组。
2.&& WeakHashMap的Entry比较特殊，它的继承体系结构为Entry-&WeakReference-&Reference 。
3.& Reference 里面有一个全局锁对象：Lock，它也被称为pending_lock.&&& 注意：它是静态对象。
4.&&&&&& Reference& 里面有一个静态变量：pending。
5.& Reference& 里面有一个静态内部类：ReferenceHandler的线程，它在static块里面被初始化并且启动，启动完成后处于wait状态，它在一个Lock同步锁模块中等待。
6.& 另外，WeakHashMap里面还实例化了一个ReferenceQueue列队，这个列队的作用，后面会提到。
7.& 上面关键点就介绍完毕了，下面我们把他们串起来。
&&&& 假设，WeakHashMap对象里面已经保存了很多对象的引用。 JVM 在进行CMS GC的时候，会创建一个ConcurrentMarkSweepThread（简称CMST）线程去进行GC，ConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread（简称SLT）线程并且启动它，SLT启动之后，处于等待阶段。CMST开始GC时，会发一个消息给SLT让它去获取Java层Reference对象的全局锁：Lock。 直到CMS GC完毕之后，JVM 会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference 的pending属性当中（每次GC完毕之后，pending属性基本上都不会为null了），然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法，使其脱离wait状态，开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中，比如当前这个WeakReference属于某个WeakHashMap对象，那么它就会被放入相应的ReferenceQueue列队里面（该列队是链表结构）。 当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候，WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较，如果发现相同的，则说明这个Entry所保存的对象已经被GC掉了，那么将Entry[]内的Entry对象剔除掉。
taskObjectTimerFactory JVM &&&&&&&&& 顾名思义，该线程就是用来执行任务的。 当我们把一个认为交给Timer对象，并且告诉它执行时间，周期时间后，Timer就会将该任务放入任务列队，并且通知taskObjectTimerFactory线程去处理任务，taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除，如果任务是非重复执行类型的，则在执行完该任务后，将它从任务列队中移除，如果该任务是需要重复执行的，则计算出它下一次执行的时间点。
VM Periodic Task Thread JVM &&&&&&& 该线程是JVM周期性任务调度的线程，它由WatcherThread创建，是一个单例对象。 该线程在JVM内使用得比较频繁，比如：定期的内存监控、JVM运行状况监控，还有我们经常需要去执行一些jstat 这类命令查看gc的情况，如下：
jstat -gcutil && 这个命令告诉jvm在控制台打印PID为：23483的gc情况，间隔250毫秒打印一次，一共打印7次。
VM Thread JVM &&&&&&&& 这个线程就比较牛b了，是jvm里面的线程母体，根据hotspot源码（vmThread.hpp）里面的注释，它是一个单例的对象（最原始的线程）会产生或触发所有其他的线程，这个单个的VM线程是会被其他线程所使用来做一些VM操作（如，清扫垃圾等）。
&&&&&&&& 在 VMThread 的结构体里有一个VMOperationQueue列队，所有的VM线程操作(vm_operation)都会被保存到这个列队当中，VMThread 本身就是一个线程，它的线程负责执行一个自轮询的loop函数(具体可以参考：VMThread.cpp里面的void VMThread::loop()) ，该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation)，并且调用VM_Operation-&evaluate函数去执行该操作类型本身的业务逻辑。
&&&&&& ps：VM操作类型被定义在vm_operations.hpp文件内，列举几个：ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学，可以自己去查看源文件。
(搬运自 http://blog.csdn.net/a/article/details/8134234 感谢原著作者)
2．Jmap
2.1&& 得到运行java程序的内存分配的详细情况。例如实例个数，大小等
2.2&& 命名行格式
jmap [ option ] pid
jmap [ option ] executable core
jmap [ option ] [server-id@]remote-hostname-or-IP
-dump:[live,]format=b,file=&filename& 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件.
-finalizerinfo 打印正等候回收的对象的信息.
-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.
-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量.
-permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.
-F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效.
-h | -help 打印辅助信息
-J 传递参数给jmap启动的jvm.
2.3&& 使用例子
jmap -histo pid(查看实例)
jmap -dump:format=b,file=heap.bin pid(导出内存，据说对性能有影响，小心使用)
(format=b是通过二进制的意思，但是能不能导出文本文件我没找到，知道的告诉我)
把内存结构全部dump到二进制文件中，通过IBM的HeapAnalyzer和eclipse的MemoryAnalyzer都可以分析内存结构。
这个是我用HeapAnalyzer查看出的我们daily的内存结构，已经列出了可能存在的问题。(这个工具我不熟悉，只供大家参考)
下面是我用eclipse 的MemoryAnalyzer查看内存结构图
上面的是eclipse分析内存泄漏分析出的。这个功能点非常多。可以慢慢学习
3．Jstat
3.1&& 这是一个比较实用的一个命令，可以观察到classloader，compiler，gc相关信息。可以时时监控资源和性能
3.2&&&&& 命令格式
-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
3.3&& 输出参数内容
S0& — Heap上的 Survivor space 0 区已使用空间的百分比
S0C：S0当前容量的大小
S0U：S0已经使用的大小
S1& — Heap上的 Survivor space 1 区已使用空间的百分比
S1C：S1当前容量的大小
S1U：S1已经使用的大小
E&& — Heap上的 Eden space 区已使用空间的百分比
EC：Eden space当前容量的大小
EU：Eden space已经使用的大小
O&& — Heap上的 Old space 区已使用空间的百分比
OC：Old space当前容量的大小
OU：Old space已经使用的大小
P&& — Perm space 区已使用空间的百分比
OC：Perm space当前容量的大小
OU：Perm space已经使用的大小
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)，它的值等于YGC+FGC
例子2(连续5次)
例子3(PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量)
这个工具的参数非常多，据说基本能覆盖jprofile等收费工具的所有功能了。多用用对于系统调优还是很有帮助的
注1：我们在daily用这样命令时，都要用-F参数的。因为我们的用户都不是启动命令的用户
注2：daily的这些命令好像都没有配置到环境变量里面，这个是我在自己应用机器里面看到的。需要去jdk目录底下执行。Sudo当然是必须的了
浏览 82951
浏览: 226934 次
来自: 杭州
才发现这贴子好早
请问一下，这样安装上windows会不会把已经装好的linux ...
写的很不错，可以写个文件给合并的方法么？，将分割后的几份文件还 ...
3Q，刚出现这个问题解决了。
shell 双击选中太不智能了。
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'&&线程与内存交互操作&&
&&&&&&&& 所有的变量（实例字段，静态字段，构成数组对象的 元素，不包括局部变量和方法参数）都存储在主内存中，每个线程有自己的工作内存，线程的工作内存保存被线程使用到变量的主内存副本拷贝。线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存的变量。不同线程之间也不能直接访问对方工作内存中的变量，线程间变量值的传递通过主内存来完成。&Java内存模型定义了八种操作
lock（锁定）：作用于主内存的变量，它把一个变量标识为一个线程独占的状态
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
read（读取）：作用于主内存的变量，它把一个变量的值从主内存传送到线程中的工作内存，以便随后的load动作使用
load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存中的变量
store（存储）：作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便随后的write操作
write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值写入主内存的变量中
Java内存模型还规定了执行上述8种基本操作时必须满足如下规则
& && 1、不允许read和load、store和write操作之一单独出现，以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其他指令的。
& && 2、不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
& && 3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
& && 4、一个新的变量只能从主内存中&诞生&，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
& & 5、一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
& &&6、如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
& & 7、如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
&&& 8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）。
volatile关键字的作用
&&&&&&& 保证了新值能立即存储到主内存，每次使用前立即从主内存中刷新。&&&&&&&&&禁止指令重排序优化。&&&&&&&&&注：volatile关键字不能保证在多线程环境下对共享数据的操作的正确性。可以使用在自己状态改变之后需要立即通知所有线程的情况下。&&&&
&&&&&&& final类型的域是不能修改的，除了这一点外，在Java内存模型中，final域还有着特殊的语义，final域能确保初始化过程的安全性，从而可以不受限制地访问不可变对象，并在共享这些对象时无须同步。具体而言，就是被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把&this&的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到&初始化了一半&的对象），那么在其他线程中就能看到final字段的值，而且其外、外部可见状态永远也不会改变。它所带来的安全性是最简单最纯粹的。
阅读(...) 评论()> 转载: Java 多线程内存模型
转载: Java 多线程内存模型
2018阿里云全部产品优惠券(升级也可以使用，强烈推荐!!!)领取地址：
相关推荐：1、Java内存区域划分： 运行时的数据区:方法区和堆（各个线程共享的内存区域），程序计数器、Java虚拟机栈和本地方法栈（线程私有的） 程序计数器：当前线程所执行字节码的行号指示器，字节码解释器就是通过改变计算器的值来选取下一条需要执行的字节码指令，
&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Java 多线程内存模型
&&& Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model,JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果。在此之前，主流程序怨言(如C/C++等)直接使用物理硬件(或者说操作系统的内存模型)，因此，会由于不同的平台上内存模型差异，导致程序在一套平台上并发完成正常，而在另一套平台上并发访问却经常出错，因此经常需要针对不同的平台来编写程序。
&&& Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
&&& Java内存模型规定了所有变量都存储在主内存中，每条线程都有自己的工作内存，线程的工作内存保存了被该线程使用到变量的主内存副本拷贝，线程对变量的所有操作(读取,赋值等)都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程也不能直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，线程，主内存，工作内存三者的交互关系如图所示。
关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作同步回主内存之类的实现细节，Java内存模型中定义了八种操作来完成：
lock(锁定)：作用于主内存的变量它拔一个变量标识为一条线程独占的状态。
unlock(解锁)：作用于主内存的变量，它把一个处于锁定状态变量释放出来，释放后的变量才可以被其他线程锁定。
read(读取)：作用于主内的变量，把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
load(载入)：作用于工作内存的变量，把read读取操作从主内存中得到的变量值放入工作内存的变量拷贝中。
use(使用)：作用于工作内存的变量，把工作内存中一个变量的值传递给java虚拟机执行引擎，每当虚拟机遇到一个需要使用到变量值的字节码指令时将会执行该操作。
assign(赋值)：作用于工作内存变量，相关推荐：java多线程实现内存可见性的两种方式 何为内存可见性 何为共享变量 JMM两条规定 JMM关于synchronized的两条规定 线程执行 互斥代码的过程 重排序 as-if-serial 导致共享变量在线程间不可见的原因 volatile关键字 volatile如何实现内存可见性 线程写volatile变把一个从执行引擎接收到的变量的值赋值给工作变量，每当虚拟机遇到一个给变量赋值的字节码时将会执行该操作。
store(存储)：作用于工作内存的变量，把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。&
write(写入)：作用于主内存的变量，把store操作从工作内存中得到的变量值放入主内存的变量中。
&&& 如果把一个变量从主内存复制到工作内存，那就需要顺序地执行read和load操作，如果要把变量从工作内存同步到主内存，就要顺序地执行store和write操作。注意Java内存模型只要求上述两个操作必须按照顺序执行，而没有保证必须是连续执行。也即是说read和load之间，store和write之间是可插入其他指令的，如对主内存中的变量a,b进行访问时，一种可能的顺序是read a,read b,load b,load a。除此之外，Java内存模型还规定了在执行上述八种基本操作时必须满足如下规则：
不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取可但工作内存不接受，或者从工作内存发起了回写但竹内薰不接受的情况出现。
不允许一个线程丢弃它的最近的assign赋值操作，即工作内存变量值改变之后必须同步回主内存。
只有发生过assign赋值操作的变量才需要从工作内存同步回主内存。
一个新变量只能在主内存中产生，不允许在工作内存中直接使用一个未被初始化(load或assign)的变量，即一个变量在进行use和store操作之前，必须先执行过assgin和load操作
一个变量在同一时刻只允许一条线程对其进行lock锁定操作，但是lock锁定可以被一条线程重复执行多次，多次执行lock之后，只有执行相同次数的unlock操作变量才会被解锁
如果对一个变量执行lock锁定操作，将会清空工作内存中该变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
如果一个变量事先没有被lock锁定，则不允许对这个变量进行unlock解锁操作，也不允许对一个被别的线程锁定的变量进行unlock解锁。
一个变量进行unlock解锁操作之前，必须先把此变量同步回主内存中(执行store和write操作)。[/color]
Java 多线程内存模型
Java虚拟机规范中试图定义一种Java内存模型(Java Memory Model,JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各
------分隔线----------------------------
相关阅读排行
相关最新文章
Coin163.com ( Coin163 ) All Rights Reserved &&