189 8069 5689
试试修改sqldeveloper\sqldeveloper\bin\sqldeveloper.conf文件中的SetJavaHome 为你想要修改的javaHome
创新新互联，凭借10年的成都网站设计、成都网站建设经验，本着真心·诚心服务的企业理念服务于成都中小企业设计网站有上千案例。做网站建设，选成都创新互联公司。
JAVACORE与HEAPDUMP生成大法 原创
2016-11-01 10:52:41
5点赞
Z.Virgil
码龄10年
关注
Windows平台：
ORACLE JDK：HOTSPOT
IBM JDK：V9
目录
前言
JAVACORE篇：
Windows平台：
ORACLE JDK：HOTSPOT
IBM JDK：V9
LINUX平台：
HEAPDUMP篇：
LINUX平台:
前言
在项目上我们经常要生成javacore和heapdump来进行分析。这里总结一下我自己在项目上生成这两个文件的方法。
JAVACORE篇：
JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。它是一个文本文件，打开后可以看到每一个线程的执行栈，以stack trace的显示。
通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，例如数据库查询，长期得不到响应，最终导致系统崩溃等情况。
Windows平台：
ORACLE JDK：HOTSPOT
1.jvisualvm工具
jvisualvm是sun的JDK中自带的工具，在java_home/bin/jvisualvm.exe中就可以打开。
挂在到对应的java进程后，可以直接生javacore。
2.jstack工具
jstack为JDK自带的命令行工具。
其中-l -r 可以显示出详细信息，锁信息等。
3.sendsignal工具
sendsignal工具是老外开发的一个小工具，用来生成已知进程号的java进程的javacore。
附件中有具体工具。通过sendsignal.exe pid即可生成。
4.ctrl+break按键
在Windows上启动程序的时候，可以直接在启动进程的窗口按组合键生成javacore。
然而由于NC涉及到两个java进程，一个小的导程序，一个是正式的程序。
所以用该方法只能生成引导程序的javacore。看不到生产环境的实际快照。
你还在使用Java 8么，使用的又是Oracle JDK 8么？
如果这两个答案的回答都是肯定的，那接下来我要说的就对你是非常有帮助的信息了。
其实直白点说就是以下两点：
上述两点，任意一点存在问题，那都意味着你都可能得做出改变以应对可能的风险。
Oracle在2019年4月的时候，对Oracle JDK的License做了一次变更。
后续，由于争议过大，Java SE 17及以后的JDK版本，又变更为Oracle No-Fee Terms and Conditions License协议了。
好吧，也许有点复杂，你会觉得非常绕。
简单点说，大致就是：
这样是不是比较容易理解了。
好，有什么影响？
这篇文章只讨论Java SE 8，不讨论Java SE 11及Java SE 17这两个LTS版本。因为相信国内还有相当一部分在使用Java SE 8.
对于使用Oracle Java SE 8的项目来说，通常有以下几种选择
如果你仍在使用Java SE 8u202或之前的版本，那可以放心的一点是，你不用担心需要为此付费的事情。你仍然可以免费使用这个版本。
但问题随之而来，你将不再获取到安全补丁更新了。
对于一个仍然需要继续开发与维护的项目来说，没有安全补丁更新是否是你能接受的一件事情，这是你做为技术负责人要慎重对待的一件事情。
如果你把安全看的非常重要，那选择付费来使用Java SE 8u211及之后的SE 8版本，是个不错的选择。
这仍然是个值得考虑的选择，因为对很多项目来说，相比更换其它JDK或升级至11，17等方案来说，也许付费是更廉价的方案。
还有没有其它选择？
当然还是有的，以下也是你可以考虑的选择之一。
上述的版权限制，都是针对Oracle JDK而言的，但JDK并不只有Oracle JDK，还有其它很多不同的JDK可供你选择。
比如，你一定知道的 OpenJDK ，它是一个完全开源免费的版本，你不需要为使用OpenJDK付费。
由于Oracle在19年4月的这个改变，在业界造成了很大的争议，许多团队已经迁移至使用OpenJDK了，OpenJDK的使用占比已经高于Oracle JDK了
其实，不只是OpenJDK，许多大公司基于OpenJDK都发行与维护着自己的JDK，列举一些如下：
等，这个列表其实可以很长。这些JDK发行版本都是由一些大公司基于OpenJDK构建的，也都是开源的，并且提供了一定的支持时间。
但很多Java程序员会疑问，OpenJDK与Oracle JDK究竟有什么区别，这些不同的OpenJDK发行版本是否可靠？
关于OpenJDK与Oracle JDK的区别，后续我单独再聊一下这个话题。
现在OpenJDK与Oracle JDK的代码几乎完全一样，所以可靠性是完全不用担心的，而显而易见的一个事实是，大公司自己都在用自己的发行版本，能不可靠？
如果你确实特别喜欢Oracle JDK，或只信任它。在不付费又想要有安全补丁的前提下，你仍然可以选择使用Oracle JDK 17.
Oracle JDK 17是基于Oracle No-Fee Terms and Conditions License协议，无论是个人或是商用，都可以无偿使用，只是有一定的时间限制。
Oracle宣称，这是在它们听到企业的期望之后做出的改变，因为大多数企业仍然期望使用Oracle JDK。
最后，说一下关于Java SE 8的问题。
做为一个架构师，你需要明白一点：
不使用Java SE 8，并不是一个你可以选择的事情，它只是一个时间问题
无论你有多少理由或困难在前，让你想继续使用Java SE 8，你要明白，Java SE 8终有告别的一天，它只是一个时间上的问题。
1、首先，下载JDK安装包，到oracle官首页进行下载，点左边的Java Platform (JDK1.5) 7u51进入下一个下载页面.
2、点左边的Accept License Agreement，接受许可协议，方能下载，由于我装的WIN7 64位系统，所以选对应的64位安装包
3、Windows x64 对应的 jdk-7u51-windows-x64.exe 下载，
4、下载完安装，习惯把软件装到D盘，各位可根据自己习惯改存放位置
oracle8i中为jdk1.2,
oracle9i中为jdk1.3,
oracle10g中为jdk1.4
如果你不相信可以去看系统“环境变量”中的path，因为oracle安装后会自动将其默认的jre路径写入path变量。
首先要先明确之间，以及OpenJDK 6、OpenJDK 7、OpenJDK 7u和OpenJDK 8等项目之间是什么关系，这有助于确定接下来编译要使用的JDK版本和源码分支。
从前面介绍的Java发展史中我们了解到OpenJDK是Sun在2006年末把Java开源而形成的项目，这里的“开源”是通常意义上的源码开放形式，即源码是可被复用的，例如IcedTea、UltraViolet都是从OpenJDK源码衍生出的发行版。但如果仅从“开源”字面意义（开放可阅读的源码）上看，其实Sun自JDK 1.5之后就开始以Java Research License（JRL）的形式公布过Java源码，主要用于研究人员阅读（JRL许可证的开放源码至JDK 1.6 Update 23为止）。把这些JRL许可证形式的Sun/OracleJDK源码和对应版本的OpenJDK源码进行比较，发现除了文件头的版权注释之外，其余代码基本上都是相同的，只有字体渲染部分存在一点差异，Oracle JDK采用了商业实现，而OpenJDK使用的是开源的FreeType。当然，“相同”是建立在两者共有的组件基础上的，Oracle JDK中还会存在一些Open JDK没有的、商用闭源的功能，例如从JRockit移植改造而来的Java Flight Recorder。预计以后JRockit的MissionControl移植到HotSpot之后，也会以Oracle JDK专有、闭源的形式提供。
Oracle的项目发布经理Joe Darcy在OSCON 2011上对两者关系的介绍也证实了OpenJDK 7和Oracle JDK 7在程序上是非常接近的，两者共用了大量相同的代码（如下图，注意图中提示了两者共同代码的占比要远高于图形上看到的比例），所以我们编译的OpenJDK，基本上可以认为性能、功能和执行逻辑上都和官方的Oracle JDK是一致的。
Dalvik 与java虚拟机:
1.java虚拟机基于栈。 基于栈的机器必须使用指令来载入和操作栈上数据，所需指令更多更多 .
而dalvik虚拟机是基于寄存器的：java虚拟机运行的是java字节码。
(java类会被编译成一个或多个字节码.class文件，打包到.jar文件中，java虚拟机从相应的.class文件和.jar文件中获取相应的字节码）2.Dalvik和Java之间的另外一大区别就是运行环境——Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例OpenJDK :
[root@localhost ~]# java -version
java version "1.6.0_39"
OpenJDK Runtime Environment (IcedTea6 1.13.11) (rhel-1.13.11.0.el5_11-x86_64)OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)oracle jdk:
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)OpenJDK下载：
8：yum install java-1.8.0-openjdk
JDK 7：
yum install java-1.7.0-openjdk
JDK 6:yum install java-1.6.0-openjdk
1. HotSpot历史
SUN的JDK版本从1.3.1开始运用HotSpot虚拟机， 2006年底开源，主要使用C++实现，JNI接口部分用C实现。
HotSpot是较新的Java虚拟机，用来代替JIT(Just in Time)，可以大大提高Java运行的性能。
Java原先是把源代码编译为字节码在虚拟机执行，这样执行速度较慢。而HotSpot将常用的部分代码编译为本地(原生，native)代码，这样显着提高了性能。
HotSpot JVM 参数可以分为规则参数(standard options)和非规则参数(non-standard options)。
规则参数相对稳定，在JDK未来的版本里不会有太大的改动。
非规则参数则有因升级JDK而改动的可能。
规则和非规则参数这里不做介绍了，网上资料很多。
2.HotSpot基础知识
HotSpot包括一个解释器和两个编译器（client 和 server，二选一的），解释与编译混合执行模式，默认启动解释执行。
编译器：java源代码被编译器编译成class文件（字节码），java字节码在运行时可以被动态编译（JIT）成本地代码(前提是解释与编译混合执行模式且虚拟机不是刚启动时)。
解释器： 解释器用来解释class文件（字节码），java是解释语言（书上这么说的）。
server启动慢，占用内存多，执行效率高，适用于服务器端应用；client启动快，占用内存小，执行效率没有server快，默认情况下不进行动态编译，适用于桌面应用程序。
由-XX:+RewriteFrequentPairs参数控制 client模式默认关闭，server模式默认开启在jre安装目录下的lib/i386/jvm.cfg 文件下。
java -version
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)mixed mode 解释与编译 混合的执行模式 默认使用这种模式java -Xint -version
Java HotSpot(TM) Client VM (build 14.3-b01, interpreted mode, sharing)interpreted 纯解释模式 禁用JIT编译
java -Xcomp -version
Java HotSpot(TM) Client VM (build 14.3-b01, compiled mode, sharing)compiled 纯编译模式（如果方法无法编译，则回退到解释模式执行无法编译的方法）3.动态编译
动态编译(compile during run-time)，英文称Dynamic compilation；Just In Time也是这个意思。
HotSpot对bytecode的编译不是在程序运行前编译的，而是在程序运行过程中编译的。
HotSpot里运行着一个监视器（Profile Monitor），用来监视程序的运行状况。
java字节码（class文件）是以解释的方式被加载到虚拟机中(默认启动时解释执行)。 程序运行过程中，那一部分运用频率大，那些对程序的性能影响重要。对程序运行效率影响大的代码，称为热点（hotspot），HotSpot会把这些热点动态地编译成机器码（native code），同时对机器码进行优化，从而提高运行效率。对那些较少运行的代码，HotSpot就不会把他们编译。
HotSpot对字节码有三层处理：不编译(字节码加载到虚拟机中时的状态。也就是当虚拟机执行的时候再编译)，编译(把字节码编译成本地代码。虚拟机执行的时候已经编译好了，不要再编译了)，编译并优化（不但把字节码编译成本地代码，而且还进行了优化）。
至于那些程序那些不编译，那些编译，那些优化，则是由监视器（Profile Monitor）决定。
4.为什么不静态编译那？
为什么字节码在装载到虚拟机之前就编译成本地代码那？
动态编译器也在许多方面比静态编译器优越。静态编译器通常很难准确预知程序运行过程中究竟什么部分最需要优化。
函数调用都是很浪费系统时间的，因为有许多进栈出栈操作。因此有一种优化办法，就是把原来的函数调用，通过编译器的编译，改成非函数调用，把函数代码直接嵌到调用出，变成顺序执行。
面向对象的语言支持多态，静态编译无效确定程序调用哪个方法，因为多态是在程序运行中确定调用哪个方法。
jdk 1.9 等价JDK9 J2SE9 JAVA9
jdk 1.8 等价JDK8 J2SE8 JAVA8
jdk 1.7 等价JDK7 J2SE7 JAVA7
jdk 1.6 等价JDK6 J2SE6 JAVA6
jdk 1.5 等价JDK5 J2SE5 JAVA5
jdk 1.4 等价J2SE1.4
jdk 1.3 等价J2SE1.3
jdk 1.2 等价J2SE1.2
jdk 1.1
openjdk源码下载：
Oracle JDK只发布二进制安装包，而OpenJDK只发布源码复制代码
获取OpenJDK源码有两种方式：
第一种方式：
下载OpenJDK7u的源代码：
hg clone jdk7u-dev
chmod 755 get_source.sh
./get_source.sh
下载OpenJDK8u的源代码：
hg clone jdk8u-dev
./get_source.sh
注意：这是最直接的方式，从版本管理中看变更轨迹比看Release Note效果更好。但不足之处是速度太慢，虽然代码总容量只有300 MB左右，但是文件数量太多，在笔者的网络下全部复制到本地需要数小时。
第二种方式，即直接下载官方打包好的源码包
读者可以从Source Bundle Releases页面（地址：）取得打包好的源码，到本地直接解压即可。
一般来说，源码包大概一至两个月左右会更新一次，虽然不够及时，但比起从Mercurial复制代码的确方便和快捷许多。
笔者下载的是OpenJDK 7 Update 6 Build b21版源码包，2012年8月28日发布，大概99MB，解压后约为339MB。
备注：推荐在linux平台或者mac平台上面编译jdk