java代码远程jvm java代码远程调用服务

JAVA 里面的JVM

JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范。

使用Java虚拟机实现Java语言的一个非常重要的特点就是与平台的无关性。 Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译，到处运行”的原因。

另外，JDK、JRE、JVM的关系如下：

相关问答

Q1: 深入探索Java工作原理：JVM，内存回收及其他

Java语言引入了Java虚拟机 具有跨平台运行的功能 能够很好地适应各种Web应用 同时 为了提高Java语言的性能和健壮性 还引入了如垃圾回收机制等新功能 通过这些改进让Java具有其独特的工作原理

．Java虚拟机

Java虚拟机（Java Virtual Machine JVM）是软件模拟的计算机 它可以在任何处理器上（无论是在计算机中还是在其他电子设备中）安全兼容地执行保存在 class文件中的字节码 Java虚拟机的 机器码 保存在 class文件中 有时也可以称之为字节码文件

Java程序的跨平台特性主要是指字节码文件可以在任何具有Java虚拟机的计算机或者电子设备上运行 Java虚拟机中的Java解释器负责将字节码文件解释成为特定的机器码进行运行 因此在运行时 Java源程序需要通过编译器编译成为 class文件

Java虚拟机的建立需要针对不同的软硬件平台来实现 既要考虑处理器的型号 也要考虑操作系统的种类 由此在SPARC结构 X 结构 MIPS和PPC等嵌入式处理芯片上 在UNIX Linux Windows和部分实时操作系统上都可实现Java虚拟机

．无用内存自动回收机制

在程序的执行过程中 部分内存在使用过后就处于废弃状态 如果不及时进行回收 很有可能会导致内存泄漏 进而引发系统崩溃 在C++语言中是由程序员进行内存回收的 程序员需要在编写程序时把不再使用的对象内存释放掉 这种人为管理内存释放的方法往往由于程序员的疏忽而致使内存无法回收 同时也增加了程序员的工作量 而在Java运行环境中 始终存在着一个系统级的线程 专门跟踪内存的使用情况 定期检测出不再使用的内存 并自动进行回收 避免了内存的泄露 也减轻了程序员的工作量

．代码安全性检查机制

安全和方便总是相对矛盾的 Java编程语言的出现使得客户端计算机可以方便地从网络上上传或下载Java程序到本地计算机上运行 但是如何保证该Java程序不携带病毒或者没有其他危险目的呢？为了确保Java程序执行的安全性 Java语言通过Applet程序来控制非法程序的安全性 也就是有了它才确保Java语言的生存

Java字节码的执行需要经过以下 个步骤

（ ）由类装载器（class loader）负责把类文件（ class文件）加载到Java虚拟机中 在此过程需要检验该类文件是否符合类文件规范

（ ）字节码校验器（bytecode verifier）检查该类文件的代码中是否存在着某些非法操作 例如Applet程序中写本地计算机文件系统的操作

（ ）如果字节码校验器检验通过 由Java解释器负责把该类文件解释成为机器码进行执行

注意

Java虚拟机采用 沙箱 运行模式 即把Java程序的代码和数据都限制在一定内存空间里执行 不允许程序访问该内存空间以外的内存 如果是Applet程序 还不允许访问客户端机器的文件系统

Java的运行环境

无论哪种语言都需要有它特定的运行环境 也就是平台 Java语言同样不例外 但是如何理解Java程序与硬件环境无关呢？

几乎所有的语言都需要通过编译或者解释才可以被计算机执行 但是Java有一点不同 它同时需要这两个过程 其实 也正是因为这个原因才使Java这种语言具有了平台无关性 当完成一个Java源程序后 首先 通过Java翻译程序将它编译成一种叫做字节码的中间代码 然后再由Java平台的解释器将它转换成为机器语言来执行 这一平台的核心就是JVM

Java的编译过程与其他的语言不同 像C++这样的语言 在编译时它是与计算机的硬件平台信息密不可分的 编译程序通过查表将所有指令的操作数和操作码等转换成内存的偏移量 即程序运行时的内存分配方式 目的是保证程序正常运行 而Java却是将指令转换成为一种 class的文件 这种文件不包含硬件的信息 需要执行时只要经过安装有JVM的机器进行解释 创建内存分配后再通过查表来确定一条指令所在的地址 这样就有效地保证了Java的可移植性和安全性

Java平台具有这样的特性和它的结构有关 通常一个程序运行的平台是一个硬件或者软件运行的环境 目前比较流行的是Windows XP Linux Solaris和MacOS Java的平台不太一样 它由两个部分组成 即JVM和应用程序设计接口

．JVM

JVM是Java平台的核心 为了让编译产生的字节码能更好地解释与执行 因此把JVM分成了 个部分 JVM解释器 指令系统 寄存器 栈 存储区和碎片回收区

◆JVM解释器 即这个虚拟机处理字段码的CPU

◆JVM指令系统 该系统与计算机很相似 一条指令由操作码和操作数两部分组成 操作码为 位二进制数 主要是为了说明一条指令的功能 操作数可以根据需要而定 JVM有多达 种不同的操作指令

◆寄存器 JVM有自己的虚拟寄存器 这样就可以快速地与JVM的解释器进行数据交换 为了功能的需要 JVM设置了 个常用的 位寄存器 pc（程序计数器） optop（操作数栈顶指针） frame（当前执行环境指针）和vars（指向当前执行环境中第一个局部变量的指针）

◆JVM栈 指令执行时数据和信息存储的场所和控制中心 它提供给JVM解释器运算所需要的信息

◆存储区 JVM存储区用于存储编译过后的字节码等信息

◆碎片回收区 JVM碎片回收是指将使用过的Java类的具体实例从内存进行回收 这就使得开发人员免去了自己编程控制内存的麻烦和危险 随着JVM的不断升级 其碎片回收的技术和算法也更加合理 JVM 版后产生了一种叫分代收集技术 简单来说就是利用对象在程序中生存的时间划分成代 以此为标准进行碎片回收

．Java应用程序设计接口

Java Application Programming Interface简称Java API 其中文名为Java应用程序设计接口 它是一个软件集合 其中有许多开发时所需要的控件 可以用它来辅助开发

lishixinzhi/Article/program/Java/hx/201311/26733

Q2: 使用jvm怎么运行java程序

1.jvm，java

virtual

machine，也就是java虚拟机。

2.只是要运行java程序的话，你只需要jre就可以。正是因为jvm，java才可以在任何平台上运行。3.没有jre是无法运行java程序的。windows是不会自带jre的。。。似乎很久以前有过，不过sun和ms发生了一点小矛盾。。。。linux系统倒是有的

Q3: java代码怎么设定启动时的JVM参数

不管是YGC还是Full GC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数java代码远程jvm，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），所以使用的GC种类也会不同(如何选择见GC种类及如何选择)。本文将注重介绍JVM、GC的一些重要参数的设置来提高系统的性能。

GC性能方面的考虑

对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。

1. Total Heap

默认情况下，vm会增加/减少heap大小以维持free space在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。

一般而言，server端的app会有以下规则：

对vm分配尽可能多的memoryjava代码远程jvm；

将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。

处理器核数增加，内存也跟着增大。

2. The Young Generation

另外一个对于app流畅性运行影响的因素是young generation的大小。young generation越大，minor collection越少java代码远程jvm；但是在固定heap size情况下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection会引发minor collection)。

NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，将这两个值设为一样就固定了young generation的大小（同Xms和Xmx设为一样）。

如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。SurvivorRatio是eden和survior大小比例。

一般而言，server端的app会有以下规则：

首先决定能分配给vm的最大的heap size，然后设定最佳的young generation的大小；

如果heap size固定后，增加young generation的大小意味着减小tenured generation大小。让tenured generation在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

经验规则

年轻代大小选择

响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.

吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.

避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁 2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.

年老代大小选择

响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:

并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。

吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.

较小堆引起的碎片问题

因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:

-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.

-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩

用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大

XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力

使用CMS的好处是用尽量少的新生代，经验值是128M－256M， 然后老生代利用CMS并行收集， 这样能保证系统低延迟的吞吐效率。 实际上cms的收集停顿时间非常的短，2G的内存， 大约20－80ms的应用程序停顿时间

系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)

仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。

采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿

JVM参数的设置(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

promotion failed:

垃圾回收时promotion failed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向Full GC，网站停顿时间较长。

解决方方案一：

第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。

解决方案一的改进方案：

又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值与Xmn的关系公式

上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor old gen区剩余内存时，不会出现promontion faild的情况，即：

(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：

CMSInitiatingOccupancyFraction =((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

当xmx=128 xmn=36 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

当xmx=128 xmn=24 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

当xmx=3000 xmn=600 SurvivorRatior=1时 CMSInitiatingOccupancyFraction=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。

Q4: java代码控制azure虚拟机，比如添加，删除等操作。求具体步骤，用eclipse或netbeans

最近，使用Powershell脚本在A7 (8核，56G内存)配置的 Azure VM（Virtual Machine，虚拟机）上远程运行Java JVM时 （Java.exe -version），总是失败并返回如下的错误信息。同样的Powershell脚本，在其它低于A7配置的VM上远程执行一切正常；此外，如果使用远程桌面登录到VM上，再进行同样的操作，一切执行正常。

[plain] view plain copy

Error occurred during initialization of VM

Unable to allocate 458752KB bitmaps for parallel garbage collection for the requested 14680064KB heap.

Error occurred during initialization of VM

Could not reserve enough space for object heap

以上的实验排除了是JVM（1.7）本身的问题， 看来问题很有可能是出在Powershell的远程执行方式上。Powershell Remoting依赖于WinRM (Windows Remote Management)在远程机器上执行操作。默认情况下，WinRM为每个Powershell远程连接分配了最大(MaxMemoryPerShellMB=1024)1G的内存空间（早期的版本只有150M），用于执行远程操作。但远程操作所需的执行内存空间 1G时，就会出现了内存不足的问题，不同的操作可能表现会有所不同，如：有的会抛出OutOfMemoryException等。针对这个问题，解决的办法就是增加MaxMemoryPerShellMB，然后重启WinRM服务：

[plain] view plain copy

$maxMemoryPerShellVM = 3072

Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB $maxMemoryPerShellVM

Set-Item WSMan:\localhost\Plugin\Microsoft.PowerShell\Quotas\MaxMemoryPerShellMB $maxMemoryPerShellVM

Write-Output "List MaxMemoryPerShellMB configuration"

Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB

Get-Item WSMan:\localhost\Plugin\Microsoft.PowerShell\Quotas\MaxMemoryPerShellMB

# Restart WinRM service to make the change take effect

Restart-Service winrm

具体要增加到多大的内存，需要自己去实验一下。

java代码远程jvm的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java代码远程调用服务、java代码远程jvm的信息别忘了在本站进行查找喔。