「远程测试java」远程测试端口

今天给各位分享远程测试java的知识，其中也会对远程测试端口进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何实现远程调试java代码
• 2、如何对生产环境的JAVA应用进行远程调试
• 3、如何在本地debug远程java
• 4、用Java检测远程主机是否能被连接
• 5、java的远程调试是基于什么协议
• 6、如何使用 Idea 远程调试 Java 代码

如何实现远程调试java代码

1. 远程debug调试java代码

1.1 主动连接调试

首先需要远程服务配置启动脚本:

JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000"

如果是启动jar包，指令：

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -jar test.jar

这里-Xdebug是通知JVM工作在DEBUG模式下，-Xrunjdwp是通知JVM使用(java debug wire protocol)来运行调试环境。

transport是监听Socket端口连接方式（也可以dt_shmem共享内存方式，但限于windows机器，并且服务提供端和调试端只能位于同一台机）。

server=y表示当前是调试服务端，=n表示当前是调试客户端。suspend=n表示启动时不中断（如果启动时中断，一般用于调试启动不了的问题）。

address=8000表示本地监听8000端口。

远程服务（tomcat/jboss）启动成功后，本地Eclipse对需要调试的地方打上断点，

然后项目右键启动远程调试：Debug as-Debug Configurations-Remote Java Application。

Host为远程主机IP，Port为远程监听调试端口，Connection Type为：Standard(Socket Attach)，

点击Debug，然后打断点，远程服务运行到断点处本地就会中断，然后进行调试。

1.2 被动连接调试

首先需要Eclipse配置监听，如主动连接调试的Eclipse配置图片，Connection Type选择：

Standard(Socket Listen)，配置本地监听端口，比如默认8000。点击Debug开始等待远程连接调试。

然后配置远程服务启动脚本：

JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000,suspend=y"

如果是调试jar包，指令：

java -Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000,suspend=y -jar remoting-debug.jar

参数含义和主动连接调试一样，只是这里suspend=y表示启动时就中断，需要连接本地IDE调试启动。

address=ip:port，ip需要修改为本地的对外IP。

这样远程项目启动时就连接到本地，方便调试项目启动不了的问题。

如何对生产环境的JAVA应用进行远程调试

通过开启jdwp功能可以进行eclipse连接远端tomcat的调试。

参考地址：

但是通常情况下，建议通过以输出日志或者测试服务器测试的方式进行调试，生产环境能不动就不动。否则会出大问题的。

如何在本地debug远程java

Eclipse 两种方法 1、先设置好断点 2、启动Debug模式时，设置到main暂停 1、远程debug（这个大家基本都会） 就是本机的eclipse来debug远程的java进程，需要两个步骤。 第一个：java进程启动的时候，加入可以debug的参数

用Java检测远程主机是否能被连接

有人推荐使用java的Runtime.exec()方法来直接调用系统的Ping命令。也有人完成了纯Java实现Ping的程序，使用的是Java的NIO包(native io, 高效IO包)。

我个人认为，没有必要用Java再重新写一个Ping命令，因为没有多大意义。更多的人是关心用Java实现ping在应用程序中来测试一个远程主机是否可用。其实自从Java 1.5，java.net包中就实现了ICMP ping的功能。以下我来介绍：

自java 1.5以后，java.net.InetAddress中一个方法：Java代码public boolean isReachable(int timeout) throws IOException

public boolean isReachable(int timeout) throws IOException 它实现了ICMP ECHO REQUEST。

用法如下：Java代码String host = "192.168.1.181"

int timeOut = 3000; //超时应该在3钞以上

boolean status = InetAddress.getByName(host).isReachable(timeOut);

String host = "192.168.1.181"

int timeOut = 3000; //超时应该在3钞以上

boolean status = InetAddress.getByName(host).isReachable(timeOut); 当返回值是true时，说明host是可用的，反正则不可。

使用时应注意，如果远程服务器设置了防火墙或相关的配制，可能会影响到结果，也是无法避免的。

java的远程调试是基于什么协议

RMI是java语言本身提供的远程通讯协议，稳定高效，是EJB的基础。但它只能用于JAVA程序之间的通讯。

Hessian和Burlap是caucho公司提供的开源协议，基于HTTP传输，服务端不用开防火墙端口。协议的规范公开，可以用于任意语言。

Httpinvoker是SpringFramework提供的远程通讯协议，只能用于JAVA程序间的通讯，且服务端和客户端必须使用SpringFramework。

Web service是连接异构系统或异构语言的首选协议，它使用SOAP形式通讯，可以用于任何语言，目前的许多开发工具对其的支持也很好。

RMI Httpinvoker = Hessian Burlap web service

RMI不愧是JAVA的首选远程调用协议，非常高效稳定，特别是在大数据量的情况下，与其他通讯协议的差距尤为明显。

HttpInvoker使用java的序列化技术传输对象，与RMI在本质上是一致的。从效率上看，两者也相差无几，HttpInvoker与RMI的传输时间基本持平。

Hessian在传输少量对象时，比RMI还要快速高效，但传输数据结构复杂的对象或大量数据对象时，较RMI要慢20%左右。

Burlap仅在传输1条数据时速度尚可，通常情况下，它的毫时是RMI的3倍。

Web Service的效率低下是众所周知的，平均来看，Web Service的通讯毫时是RMI的10倍。

二、结果分析

1、直接调用

直接调用的所有毫时都接近0，这说明程序处理几乎没有花费时间，记录的全部时间都是远程调用耗费的。

2、RMI调用

与设想的一样，RMI理所当然是最快的，在几乎所有的情况下，它的毫时都是最少的。特别是在数据结构复杂，数据量大的情况下，与其他协议的差距尤为明显。

为了充分发挥RMI的性能，另外做了测试类，不使用Spring，用原始的RMI形式 （继承UnicastRemoteObject对象）提供服务并远程调用，与Spring对POJO包装成的RMI进行效率比较。结果显示：两者基本持 平，Spring提供的服务还稍快些。

初步认为，这是因为Spring的代理和缓存机制比较强大，节省了对象重新获取的时间。

3、Hessian调用

caucho公司的resin服务器号称是最快的服务器，在java领域有一定的知名 度。Hessian做为resin的组成部分，其设计也非常精简高效，实际运行情况也证明了这一点。平均来看，Hessian较RMI要慢20%左右，但 这只是在数据量特别大，数据结构很复杂的情况下才能体现出来，中等或少量数据时，Hessian并不比RMI慢。

Hessian的好处是精简高效，可以跨语言使用，而且协议规范公开，我们可以针对任意语言开发对其协议的实现。目前已有实现的语言有：java, c++, .net, python, ruby。还没有delphi的实现。

另外，Hessian与WEB服务器结合非常好，借助WEB服务器的成熟功能，在处理大 量用户并发访问时会有很大优势，在资源分配，线程排队，异常处理等方面都可以由成熟的WEB服务器保证。而RMI本身并不提供多线程的服务器。而 且，RMI需要开防火墙端口，Hessian不用。

4、Burlap调用

Burlap与Hessian都是caucho公司的开源产品，只不过Hessian采用二进制的方式，而Burlap采用xml的格式。

测试结果显示，Burlap在数据结构不复杂，数据量中等的情况下，效率还是可以接受的，但如果数据量大，效率会急剧下降。平均计算，Burlap的调用毫时是RMI的3倍。

我认为，其效率低有两方面的原因，一个是XML数据描述内容太多，同样的数据结构，其传输量要大很多；另一方面，众所周知，对xml的解析是比较费资源的，特别对于大数据量情况下更是如此。

5、HttpInvoker调用

HttpInvoker是SpringFramework提供的JAVA远程调用方法，使用java的序列化机制处理对象的传输。从测试结果看，其效率还是可以的，与RMI基本持平。

不过，它只能用于JAVA语言之间的通讯，而且，要求客户端和服务端都使用SPRING框架。

另外，HttpInvoker 并没有经过实践的检验，目前还没有找到应用该协议的项目。

6、web service调用

本次测试选用了apache的AXIS组件作为WEB SERVICE的实现，AXIS在WEB SERVICE领域相对成熟老牌。

为了仅测试数据传输和编码、解码的时间，客户端和服务端都使用了缓存，对象只需实例化一次。但是，测试结果显示，web service的效率还是要比其他通讯协议慢10倍。

如果考虑到多个引用指向同一对象的传输情况，web service要落后更多。因为RMI，Hessian等协议都可以传递引用，而web service有多少个引用，就要复制多少份对象实体。

Web service传输的冗余信息过多是其速度慢的原因之一，监控发现，同样的访问请求，描述相同的数据，web service返回的数据量是hessian协议的6.5倍。另外，WEB SERVICE的处理也很毫时，目前的xml解析器效率普遍不高，处理xml - bean很毫资源。从测试结果看，异地调用比本地调用要快，也从侧面说明了其毫时主要用在编码和解码xml文件上。这比冗余信息更为严重，冗余信息占用的 只是网络带宽，而每次调用的资源耗费直接影响到服务器的负载能力。（MS的工程师曾说过，用WEB SERVICE不能负载100个以上的并发用户。）

测试过程中还发现，web service编码不甚方便，对非基本类型需要逐个注册序列化和反序列化类，很麻烦，生成stub更累，不如spring + RMI/hessian处理那么流畅简洁。而且，web service不支持集合类型，只能用数组，不方便。

ITjob学。到的

如何使用 Idea 远程调试 Java 代码

项目的部署方式有在本地搭建服务器进行启动或是debug，或是将项目在远程服务器上面部署。一般如果在本地搭建服务器的时候，可以直接选择启动或是直接debug，但是如果项目部署在远程的服务器上面的时候， 我们该如何进行调试呢？而一些大公司的项目是不需要在本地搭建应用服务器的，为了环境统一，应用服务器都是在远程服务器上面，这时我们就需要用远程debug，通过远程服务器的ip地址和远程开启的debug端口进行调试：

1.首先把远程服务器上面需要调试的代码放在IDE里面

2.在菜单栏选择run -edit Configuration，点击+号，选择remote，然后在配置项里面输入远程需要调试机器的IP地址和所对应的端口号，最后在最上面输入该次一远程调试的项目名字，方便自己区分不同的项目

3.将配置项中的-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5080添加到JAVA_OPTS的属性中，重启远程tomcat服务器

3.再次选择菜单条run按钮，找到debug+“自己设置的项目名字”，点击然后就可以进行远程debug调试

4.在本地项目中设置断点，然后访问远程机器上面的IP和端口，然后就可以在本地debug调试了

远程测试java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于远程测试端口、远程测试java的信息别忘了在本站进行查找喔。