Java RMI 实战指南

需积分: 10 79 浏览量更新于2024-07-29 收藏 2.26MB PDF 举报

"java-rmi参考" 本书是关于Java Remote Method Invocation (RMI) 的专业参考资料，由William Grosso撰写，并由O'Reilly出版社在2001年首次出版。这是一本深入探讨Java RMI技术的书籍，包含了大量实用技巧，帮助开发者提升RMI代码的性能和效率。书中详细讲解了多个关键主题，包括但不限于： 1. 序列化：Java RMI依赖于序列化来在网络间传输对象。序列化是将对象的状态转换为字节流，以便在网络上传输或存储，然后在另一端进行反序列化恢复的过程。 2. 线程管理：在分布式环境中，理解和处理线程是至关重要的，因为RMI调用可能在不同的线程上下文中执行。 3. RMI注册表：注册表是RMI系统的核心组件，用于查找和绑定远程对象的引用。 4. Sockets和Socket工厂：RMI的基础是网络通信，本书深入介绍了如何使用和自定义套接字行为。 5. 激活：RMI激活机制允许对象在需要时动态创建，减少了资源消耗。 6. 动态类下载：RMI允许在运行时下载类，使得远程对象可以使用客户端可能没有的类。 7. HTTP隧道：有时，由于防火墙或其他安全策略，需要通过HTTP进行RMI通信，书中会讲解如何实现。 8. 分布式垃圾收集：在RMI环境中，理解如何有效地进行垃圾收集以防止内存泄漏是必要的。 9. Java Naming and Directory Interface (JNDI)：JNDI提供了一种通用接口来查找和访问命名和目录服务，RMI可以利用它来定位远程对象。 10. Common Object Request Broker Architecture (CORBA)：虽然RMI和CORBA都是分布式计算模型，但它们有不同之处，书中会讨论两者的交互和比较。作者Grosso通过丰富的示例代码和实战策略，将这些复杂的概念转化为易于理解的教程。书中的例子涵盖了从基础的流操作到构建一个基于套接字的打印机服务器等实际应用场景，旨在帮助读者掌握RMI的各个方面。此外，书中还包含了关于示例代码的说明、使用的约定、进一步学习的资源以及联系作者的方式，方便读者深入研究和反馈问题。这是一本面向中级到高级Java开发者的宝贵资源，旨在帮助他们充分利用Java RMI的强大功能，构建高效、可靠的分布式应用程序。

marked at any given time.

1.1.1.3 Resource management

Because streams are often associated with external devices such as files or network connections,

using a stream often requires the operating system to allocate resources beyond memory. For

example, most operating systems limit the number of files or network connections that a program

can have open at the same time. The resource management methods of the InputStream class

involve communication with native code to manage operating system-level resources.

The only resource management method defined for InputStream is close( ). When you're

done with a stream, you should always explicitly call close( ). This will free the associated

system resources (e.g., the associated file descriptor for files).

At first glance, this seems a little strange. After all, one of the big advantages of Java is that it has

garbage collection built into the language specification. Why not just have the object free the

operating-system resources when the object is garbage collected?

The reason is that garbage collection is unreliable. The Java language specification does not

explicitly guarantee that an object that is no longer referenced will be garbage collected (or even

that the garbage collector will ever run). In practice, you can safely assume that, if your program

runs short on memory, some objects will be garbage collected, and some memory will be

reclaimed. But this assumption isn't enough for effective management of scarce operating-system

resources such as file descriptors. In particular, there are three main problems:

• You have no control over how much time will elapse between when an object is eligible to

be garbage collected and when it is actually garbage collected.

• You have very little control over which objects get garbage collected.

[2]

You can use SoftReference (defined in java.lang.ref) to get a minimal level of control over

the order in which objects are garbage collected.

• There isn't necessarily a relationship between the number of file handles still available

and the amount of memory available. You may run out of file handles long before you run

out of memory. In which case, the garbage collector may never become active.

Put succinctly, the garbage collector is an unreliable way to manage anything other than memory

allocation. Whenever your program is using scarce operating-system resources, you should

explicitly release them. This is especially true for streams; a program should always close

streams when it's finished using them.

1.1.2 IOException

All of the methods defined for InputStream can throw an IOException. IOException is a

checked exception. This means that stream manipulation code always occurs inside a

try/catch block, as in the following code fragment:

try{

while( -1 != (nextByte = bufferedStream.read( ))) {

char nextChar = (char) nextByte;

...

}

catch (IOException e) {

...

}

The idea behind IOException is this: streams are mostly used to exchanging data with devices

that are outside the JVM. If something goes wrong with the device, the device needs a universal

way to indicate an error to the client code.

Consider, for example, a printer that refuses to print a document because it is out of paper. The

printer needs to signal an exception, and the exception should be relayed to the user; the

program making the print request has no way of refilling the paper tray without human

intervention. Moreover, this exception should be relayed to the user immediately.

Most stream exceptions are similar to this example. That is, they often require some sort of user

action (or at least user notification), and are often best handled immediately. Therefore, the

designers of the streams library decided to make IOException a checked exception, thereby

forcing programs to explicitly handle the possibility of failure.

Some foreshadowing: RMI follows a similar design

philosophy. Remote methods must be declared to throw

RemoteException (and client code must catch

RemoteException). RemoteException means "something

has gone wrong, somewhere outside the JVM."

1.1.3 OutputStream

OutputStream is an abstract class that represents a data sink. Once it is created, client code

can write information to it. OutputStream consists of the following methods:

public void close( ) throws IOException

public void flush( ) throws IOException

public void write(byte[] buffer) throws IOException

public void write(byte[] buffer, int startingOffset, int numberOfBytes)

throws

IOException

public void write(int value) throws IOException

The OutputStream class is a little simpler than InputStream; it doesn't support navigation.

After all, you probably don't want to go back and write information a second time. OutputStream

methods serve two purposes: writing data and resource management.

1.1.3.1 Writing data

OutputStream defines three basic methods for writing data:

public void write(byte[] buffer) throws IOException

public void write(byte[] buffer, int startingOffset, int numberOfBytes)

throws

IOException

public void write(int value) throws IOException

These methods are analogous to the read( ) methods defined for InputStream. Just as there

was one basic method for reading a single byte of data, there is one basic method, write(int

value), for writing a single byte of data. The argument to this write( ) method should be an

integer between 0 and 255. If not, it is reduced to module 256 before being written.

Just as there were two array-based variants of read( ), there are two methods for writing arrays

of bytes. write(byte[] buffer) causes all the bytes in the array to be written out to the

stream. write(byte[] buffer, int startingOffset, int numberOfBytes) causes

numberOfBytes bytes to be written, starting with the value at buffer[startingOffset].

The fact that the argument to the basic write( ) method is

an integer is somewhat peculiar. Recall that read( )

returned an integer, rather than a byte, in order to allow

instances of InputStream to signal exceptional conditions.

write( ) takes an integer, rather than a byte, so that the

read and write method declarations are parallel. In other

words, if you've read a value in from a stream, and it's not -1,

you should be able to write it out to another stream without

casting it.

1.1.3.2 Resource management

OutputStream defines two resource management methods:

public void close( )

public void flush( )

close( ) serves exactly the same role for OutputStream as it did for InputStream™ itshould

be called when the client code is done using the stream and wishes to free up all the associated

operating-system resources.

The flush( ) method is necessary because output streams frequently use a buffer to store

data that is being written. This is especially true when data is being written to either a file or a

socket. Passing data to the operating system a single byte at a time can be expensive. A much

more practical strategy is to buffer the data at the JVM level and occasionally call flush( ) to

send the data en masse.

1.2 Viewing a File

To make this discussion more concrete, we will now discuss a simple application that allows the

user to display the contents of a file in a JTextArea. The application is called ViewFile and is

shown in Example 1-1. Note that the application's main( ) method is defined in the

com.ora.rmibook.chapter1.ViewFile class.

[3]

The resulting screenshot is shown in Figure

1-1.

[3]

This example uses classes from the Java Swing libraries. If you would like more information on Swing,

see Java Swing (O'Reilly) or Java Foundation Classes in a Nutshell (O'Reilly).

Figure 1-1. The ViewFile application

catch (java.io.IOException ioException)

{

_fileViewingArea.setText("\n

Error occured while reading file");

}

The important part of the code is the View button's action listener and the

copyStreamToViewingArea( ) method. copyStreamToViewingArea( ) takes an

instance of InputStream and copies the contents of the stream to the central JTextArea.

What happens when a user clicks on the View button? Assuming all goes well, and that no

exceptions are thrown, the following three lines of code from the buttons's action listener are

executed:

FileInputStream fileInputStream = _fileTextField.getFileInputStream( );

copyStreamToViewingArea(fileInputStream);

fileInputStream.close( );

The first line is a call to the getFileInputStream( ) method on _fileTextField. That is,

the program reads the name of the file from a text field and tries to open a FileInputStream.

FileInputStream is defined in the java.io* package. It is a subclass of InputStream used

to read the contents of a file.

Once this stream is opened, copyStreamToViewingArea( ) is called. copyStream-

ToViewingArea( ) takes the input stream, wraps it in a buffer, and then reads it one byte at a

time. There are two things to note here:

• We explicitly check that nextByte is not equal to -1 (e.g., that we're not at the end of the

file). If we don't do this, the loop will never terminate, and we will we will continue to

append (char) -1 to the end of our text until the program crashes or throws an

exception.

• We use BufferedInputStream instead of using FileInputStream directly.

Internally, a BufferedInputStream maintains a buffer so it can read and store many

values at one time. Maintaining this buffer allows instances of Buffered-InputStream

to optimize expensive read operations. In particular, rather than reading each byte

individually, bufferedStream converts individual calls to its read( ) method into a

single call to FileInputStream's read(byte[] buffer) method. Note that buffering

also provides another benefit. BufferedInputStream supports stream navigation

through the use of marking.

Of course, the operating system is probably already buffering

file reads and writes. But, as we noted above, even the act of

passing data to the operating system (which uses native

methods) is expensive and ought to be buffered.

1.3 Layering Streams

The use of BufferedInputStream illustrates a central idea in the design of the streams library:

streams can be wrapped in other streams to provide incremental functionality. That is, there are

really two types of streams:

Primitive streams

剩余466页未读，继续阅读

戴墨镜的虫子

粉丝: 9
资源: 21

Java RMI 实战指南

Java RMI 教程：从零开始的分布式编程入门

Java RMI 示例教程：从Oracle到本地开发

Java实现RMI分布式会议系统教程

java-RMI扫雷游戏

java进程间通讯机制代码----RMI、共享内存、Socket、管道

《EJB-RMI入门》

Java-EE-复习参考资料.doc

Distributed-Search-Service-with-RMI:（学术项目）此应用程序允许您在同时连接到服务器 PC 的多台 PC 中搜索内部文件

java rmi 参考文档

java_in_rmi.rar_Java RMI_RMI java_rmi _精通rmi

最新资源