あなたとJVMの内部構造についてのこの記事の話、マルチスレッド処理コンポーネント、JVMのスレッドシステムなどのローカル変数、配列、の観点で解決されます
JVM
JVM =クラスローダ（クラスローダー）+実行エンジン（実行エンジン）+ランタイムデータ領域（ランタイムデータ領域）
以下、この図は、キー内部の部品に設けられた典型的なJVM（コンプライアンスJVM仕様のJava SE 7版）を示しています。
マルチスレッド処理コンポーネント
マルチスレッド「または」フリースレッド「は、同時に複数の操作プログラム・スレッドを実行する能力を指す。マルチスレッドアプリケーションの一例として、別のスレッド上で実行されるスレッド上でプログラムを受信するユーザ入力として複雑な計算の様々な、単一スレッドアプリケーションにおける三のスレッド上のデータベースを更新し、ユーザは、計算やデータベースの更新が完了するのを待つ時間を費やすことができる。マルチスレッドアプリケーションでは、これらのプロセスはバックグラウンドで実行することができ、だから、時間を無駄にしないでください。マルチスレッドは、アセンブリプログラミングのための非常に強力なツールになります。マルチスレッドのコンポーネントを書き込むことによって、あなたがバックグラウンドで複雑な計算を実行するコンポーネントを作成することができ、計算中にユーザーインターフェース（UI）を可能にし自由にユーザーの入力に応じて。マルチスレッディングは強力なツールですが、あなたはそれを正しく使用することはより困難であるが、マルチスレッドコードが正しく実装されていないアプリケーションのパフォーマンスが低下する、あるいはアプリケーションがフリーズすることがあります。次のトピックマルチスレッドプログラミングの考慮事項の一部を紹介します ベストプラクティス..NET Frameworkは、コンポーネントのオプションのいくつかのマルチスレッドを提供します。System.Threading名前空間機能はオプションです。イベントベースの非同期パターンは別のオプションです。BackgroundWorkerのコンポーネントが非同期モードの実装です;これは、使用を容易にするために、パッケージアセンブリに高度な機能を提供します。
JVMのメモリ管理メカニズム
（1）メモリ領域およびメモリオーバーフロー例外
（2）ガベージコレクタとメモリ割り当て戦略
（3）仮想マシンのパフォーマンスの監視とトラブルシューティングツール
JVMのチューニング
1.JVM実行サブシステム
（1）クラスファイルの構造
（2）クラスローディング機構
（3）バイトコード実行エンジン
2.プログラムは、コードの最適化を指定してコンパイル
（1）コンパイラの最適化
（2）実行時の最適化
3.実際のチューニング事例とソリューション
JVMシステムスレッド
如果你用jconsole或者任何其他的debug工具查看，可能会看到有许多线程在后台运行。这些运行着的后台线程不包含主线程，主线程是基于执行publicstatic void main(String[]) 的需要而被创建的。而这些后台线程都是被主线程所创建。在HotspotJVM中主要的后台系统线程，见下表：
单个线程
每个线程的一次执行都包含如下的组件
程序计数器（PC）
除非当前指令或者操作码是原生的，否则当前指令或操作码的地址都需要依赖于PC来寻址。如果当前方法是原生的，那么该PC即为undefined。所有的CPU都有一个PC，通常PC在每个指令执行后被增加以指向即将执行的下一条指令的地址。JVM使用PC来跟踪正在执行的指令的位置。事实上，PC被用来指向methodarea的一个内存地址。
原生栈
不是所有的JVM都支持原生方法，但那些支持该特性的JVM通常会对每个线程创建一个原生方法栈。如果对JVM的JNI（JavaNative Invocation）采用c链接模型的实现，那么原生栈也将是一个C实现的栈。在这个例子中，原生栈中参数的顺序 、返回值都将跟通常的C程序相同。一个原生方法通常会对JVM产生一个回调（这依赖于JVM的实现）并执行一个Java方法。这样一个原生到Java的调用发生在栈上（通常在Java栈），与此同时线程也将离开原生栈，通常在Java栈上创建一个新的frame。
栈
每个线程都有属于它自己的栈，用于存储在线程上执行的每个方法的frame。栈是一个后进先出的数据结构，这可以使得当前正在执行的方法位于栈的顶部。对于每个方法的执行，都会有一个新的frame被创建并被入栈到栈的顶部。当方法正常的返回或在方法执行的过程中遇到未捕获的异常时frame会被出栈。栈不会被直接进行操作，除了push/ pop frame 对象。因此可以看出，frame对象可能会被分配在堆上，并且内存也没必要是连续的地址空间（请注意区分frame的指针跟frame对象）。
栈的限制
一个栈可以是动态的或者是有合适大小的。如果一个线程要求更大的栈，那么将抛出StackOverflowError异常；如果一个线程要求新创建一个frame，又没有足够的内存空间来分配，将会抛出OutOfMemoryError异常。
Frame
对于每一个方法的执行，一个新frame会被创建并被入栈到栈顶。当方法正常返回或在方法执行的过程中遇到未捕获的异常，frame会被出栈。
局部变量数组
局部变量数组包含了在方法执行期间所用到的所有的变量。包含一个对this的引用，所有的方法参数，以及其他局部定义的变量。对于类方法（比如静态方法），方法参数的存储索引从0开始；而对于实例方法，索引为0的槽都为存储this指针而保留。
操作数栈
操作数栈在字节码指令被执行的过程中使用。它跟原生CPU使用的通用目的的寄存器类似。大部分的字节码都把时间花费在跟操作数栈打交道上，通过入栈、出栈、复制、交换或者执行那些生产/消费值的操作。对字节码而言，那些在局部变量数组和操作数栈之间移动值的指令是非常频繁的。
动态链接
每个frame都包含一个对运行时常量池的引用。该引用指向将要被执行的方法所属的类的常量池。该引用也用于辅助动态链接。
当一个Java类被编译时，所有对存储在类的常量池中的变量以及方法的引用都被当做符号引用。一个符号引用仅仅只是一个逻辑引用而不是最终指向物理内存地址的引用。JVM的实现可以选择解析符号引用的时机，该时机可以发生在当类文件被验证后、被加载后，这称之eager或静态分析；不同的是它也可以发生在当符号引用被首次使用的时候，称之为lazy或延迟分析。但JVM必须保证：解析发生在每个引用被首次使用前，同时在该时间点，如果遇到分析错误能够抛出异常。绑定是一个处理过程，它将被符号引用标识的字段、方法或类替换为一个直接引用。这个处理过程只发生一次，因为符号引用需要被完全替换。如果一个符号引用关联着一个类，而该类还没有被解析，那么该类也会被立即加载。每个直接引用都被以偏移的方式存储，该存储结构关联着变量或方法的运行时位置。
线程之间共享
堆
堆中某个节点的值总是不大于或不小于其父节点的值；
堆总是一棵完全二叉树。
将根节点最大的堆叫做最大堆或大根堆，根节点最小的堆叫做最小堆或小根堆。常见的堆有二叉堆、斐波那契堆等。
堆的定义如下：n个元素的序列{k1,k2,ki,…,kn}当且仅当满足下关系时，称之为堆。
(ki <= k2i,ki <= k2i+1)或者(ki >= k2i,ki >= k2i+1), (i = 1,2,3,4...n/2)
若将和此次序列对应的一维数组（即以一维数组作此序列的存储结构）看成是一个完全二叉树，则堆的含义表明，完全二叉树中所有非终端结点的值均不大于（或不小于）其左、右孩子结点的值。由此，若序列{k1,k2,…,kn}是堆，则堆顶元素（或完全二叉树的根）必为序列中n个元素的最小值（或最大值）
非堆式内存
有些对象并不会创建在堆中，这些对象在逻辑上被认为是JVM机制的一部分。
非堆式的内存包括：
永久代中包含：
方法区
内部字符串
代码缓存：用于编译以及存储方法，这些方法已经被JIT编译成本地代码
内存管理
对象和数组永远都不会被显式释放，因此只能依靠垃圾回收器来自动地回收它们。
通常，以如下的步骤进行：
新对象和数组被创建在年轻代
次垃圾回收器将在年轻代上执行。那些仍然存活着的对象，将被从eden区移动到survivor区
主垃圾回收器将会把对象在代与代之间进行移动，主垃圾回收器通常会导致应用程序的线程暂停。那些仍然存活着的对象将被从年轻代移动到老年代
永久代会在每次老年代被回收的时候同时进行，它们在两者中其一满了之后都会被回收
JIT编译
JIT具体的做法是这样的:当载入一个类型时,CLR为该类型创建一个内部数据结构和相应的函数,当函数第一被调用时,JIT将该函数编译成机器语言.当再次遇到该函数时则直接从cache中执行已编译好的机器语言.
方法区
所有的线程共享相同的方法区。所以，对于方法区数据的访问以及对动态链接的处理必须是线程安全的。如果两个线程企图访问一个还没有被载入的类（该类必须只能被加载一次）的字段或者方法，直到该类被加载完成，这两个线程才能继续执行。
类的文件结构
一个被编译过的类文件包含如下的结构：
ClassFile
{ u4magic; u2minor_version; u2major_version; u2constant_pool_count;
cp_infocontant_pool[constant_pool_count – 1]; u2access_flags;
u2this_class; u2super_class; u2interfaces_count;
u2interfaces[interfaces_count]; u2fields_count;
field_infofields[fields_count]; u2methods_count;
method_infomethods[methods_count]; u2attributes_count;
attribute_infoattributes[attributes_count];}
可以使用javap命令查看被编译后的java类的字节码。
下面列出了在该类文件中，使用到的操作码：
就像在其他通用的字节码中那样，以上这些操作码主要用于跟本地变量、操作数栈以及运行时常量池打交道。
构造器有两个指令，第一个将“this”压入到操作数栈，接下来该构造器的父构造器被执行，这一操作将导致this被“消费”，因此this将从操作数栈出栈。
而对于sayHello()方法，它的执行将更为复杂。因为它不得不通过运行时常量池，解析符号引用到真实的引用。第一个操作数getstatic，用来入栈一个指向System类的静态字段out的引用到操作数栈。接下来的操作数ldc，入栈一个字符串字面量“Hello”到操作数栈。最后，invokevirtual操作数，执行System.out的println方法，这将使得“Hello”作为一个参数从操作数栈出栈，并为当前线程创建一个新的frame。
转发 转发 转发关注我私信回复“java架构”获取阿里P8架构师全面讲解JVM视频资料
以及高并发，分布式，spring源码，mybatis源码，大数据，Netty等多个技术知识点全面讲解的架构视频资料
类加载器
JVM的启动是通过bootstrap类加载器来加载一个用于初始化的类。在publicstatic void main(String[])被执行前，该类会被链接以及实例化。main方法的执行，将顺序经历加载，链接，以及对额外必要的类跟接口的初始化。
加载: 加载是这样一个过程：查找表示该类或接口类型的类文件，并把它读到一个字节数组中。接着，这些字节会被解析以确认它们是否表示一个Class对象以及是否有正确的主、次版本号。任何被当做直接superclass的类或接口也一同被加载。一旦这些工作完成，一个类或接口对象将会从二进制表示中创建。
链接: 链接包含了对该类或接口的验证，准备类型以及该类的直接父类跟父接口。简而言之，链接包含三个步骤：验证、准备以及解析（optional）
验证:该阶段会确认类以及接口的表示形式在结构上的正确性，同时满足Java编程语言以及JVM语义上的要求。
在验证阶段执行这些检查意味着在运行时可以免去在链接阶段进行这些动作，虽然拖慢了类的加载速度，然而它避免了在执行字节码的时候执行这些检查。
准备:包含了对静态存储的内存分配以及JVM所使用的任何数据结构（比如方法表）。静态字段都被创建以及实例化为它们的默认值。然而，没有任何实例化器或代码在这个阶段被执行，因为这些任务将会发生在实例化阶段。
解析:是一个可选的阶段。该阶段通过加载引用的类或接口来检查符号引用是否正确。如果在这个点这些检查没发生，那么对符号引用的解析会被推迟到直到它们被字节码指令使用之前。
实例化 类或接口，包含执行类或接口的实例化方法：<clinit>
在JVM中存在多个不同职责的类加载器。每一个类加载器都代理其已被加载的父加载器（除了bootstrap类加载器，因为它是根加载器）。
Bootstrap类加载器：当java程序运行时，java虚拟机需要装载java类，这个过程需要一个类装载器来完成。而类装载器本身也是一个java类，这就出现了类似人类的第一位母亲是如何产生出来的问题。
其实，java虚拟机中内嵌了一个称为Bootstrap的类装载器，它是用特定于操作系统的本地代码实现的，属于java虚拟机的内核，这个Bootstrap类装载器不用专门的类装载器去装载。Bootstrap类装载器负责加载java核心包中的类。
Extension 类加载器：从标准的Java扩展API中加载类。例如，安全的扩展功能集。
System 类加载器：这是应用程序默认的类加载器。它从classpath中加载应用程序类。
用户定义的类加载器：可以额外得定义类加载器来加载应用程序类。用户定义的类加载器可用于一些特殊的场景，比如：在运行时重新加载类或将一些特殊的类隔离为多个不同的分组（通常web服务器中都会有这样的需求，比如Tomcat）。
更快的类加载
一个称之为类数据共享（CDS）的特性自HotspotJVM 5.0开始被引进。在安装JVM期间，安装器加载一系列的Java核心类（如rt.jar）到一个经过映射过的内存区进行共享存档。CDS减少了加载这些类的时间从而提升了JVM的启动速度，同时允许这些类在不同的JVM实例之间共享。这大大减少了内存碎片。
方法区的位置
JVM Specification Java SE 7 Edition清楚地声明：尽管方法区是堆的一个逻辑组成部分，但最简单的实现可能是既不对它进行垃圾回收也不压缩它。然而矛盾的是利用jconsole查看Oracle的JVM的方法区（以及CodeCache）是非堆形式的。OpenJDK代码显示CodeCache相对ObjectHeap而言是VM中一个独立的域。
类加载器引用
类通常是按需加载，即第一次使用该类时才加载。由于有了类加载器，Java运行时系统不需要知道文件与文件系统。
运行时常量池
JVM对每个类型维护着一个常量池，它是一个跟符号表相似的运行时数据结构，但它包含了更多的数据。Java的字节码需要一些数据，通常这些数据会因为太大而难以直接存储在字节码中。取而代之的一种做法是将其存储在常量池中，字节码包含一个对常量池的引用。运行时常量池主要用来进行动态链接。
几种类型的数据会存储在常量池中，它们是：
数值字面量
字符串字面量
类的引用
字段的引用
方法的引用
如果你编译下面的这个简单的类：
package org.jvminternals;public class SimpleClass { public void sayHello() {System.out.println("Hello");}}
生成的类文件的常量池，看起来会像下图所示：
Constant pool: #1 = Methodref #6.#17 // java/lang/Object."<init>":()V#2 = Fieldref #18.#19 // java/lang/System.out:Ljava/io/PrintStream;#3 = String #20 // "Hello"#4 = Methodref #21.#22 // java/io/PrintStream.println:(Ljava/lang/String;)V#5 = Class #23 // org/jvminternals/SimpleClass#6 = Class #24 // java/lang/Object#7 = Utf8 <init> #8 = Utf8 ()V #9 = Utf8 Code #10 = Utf8 LineNumberTable #11 = Utf8 LocalVariableTable #12 = Utf8 this #13 = Utf8 Lorg/jvminternals/SimpleClass; #14 = Utf8 sayHello #15 = Utf8 SourceFile #16 = Utf8 SimpleClass.java #17 = NameAndType #7:#8 // "<init>":()V#18 = Class #25 // java/lang/System#19 = NameAndType #26:#27 // out:Ljava/io/PrintStream;#20 = Utf8 Hello #21 = Class #28 // java/io/PrintStream#22 = NameAndType #29:#30 // println:(Ljava/lang/String;)V#23 = Utf8 org/jvminternals/SimpleClass #24 = Utf8 java/lang/Object#25 = Utf8 java/lang/System #26 = Utf8 out#27 = Utf8 Ljava/io/PrintStream; #28 = Utf8 java/io/PrintStream #29 = Utf8 println #30 = Utf8 (Ljava/lang/String;)V
常量池中包含了下面的这些类型：
异常表
异常表存储了每个异常处理器的信息：
起始点
终止点
处理代码的PC偏移量
被捕获的异常类的常量池索引
如果一个方法定义了try-catch或try-finally异常处理器，那么一个异常表将会被创建。它包含了每个异常处理器的信息或者finally块以及正在被处理的异常类型跟处理器代码的位置。
当一个异常被抛出，JVM会为当前方法寻找一个匹配的处理器。如果没有找到，那么该方法最终会唐突地出栈当前stackframe而异常会被重新抛出到调用链（新的frame）。如果在所有的frame都出栈之前还是没有找到异常处理器，那么当前线程将会被终止。当然这也可能会导致JVM被终止，如果异常被抛出到最后一个非后台线程的话，比如该线程就是主线程。
最後の例外ハンドラは、すべての例外タイプと一致し、このタイプの例外がスローされるたびに必ず実行されます。例外なくの場合、finallyブロックは、まだ最後の方法で実行されますが、中にスローされます。return文が実行されると、それはすぐにfinallyブロックが続くにジャンプします。
文字の比較
（文字の比較）比較の文字が辞書式順序で単一文字または文字列のサイズを比較するための手順を参照して、通常サイズの比較の標準としての文字のASCII値。
記号テーブル
シンボルテーブルは、このような記録の種類と特徴として、コンパイラの仕事の過程で収集し続ける必要があり、ソースプログラム情報の構文表記法の一部を使用します。この情報は、典型的には、システム内の表形式で格納されます。定数テーブルは、集合的に、シンボル・テーブルと呼ばれる変数、配列時計、プロセスを監視、参照テーブルなど、腕時計。シンボルテーブルの組織で、建設と経営の質は直接コンパイルシステムの効率に影響を与えます。
JVMには、内部の文字列は、文字列のテーブルに格納されています。で永続的な世代に記憶されている：（ハッシュテーブル<OOP、シンボル>など）、ハッシュテーブル文字列テーブルは、シンボルマッピングオブジェクトへのポインタです。
クラスがロードされると、文字列リテラルは、「内部化」に自動的にコンパイルされ、文字テーブルに追加されます。文字列クラスの更なるインスタンスはString.internを内部呼び出すことにより、明示的にも（）。String.intern（）が呼び出されたとき、シンボルテーブルは、既に文字列が含まれている場合、その文字列への参照点が返されます。文字列が表に含まれていない場合は、文字列テーブルに追加し、その参照を返します