I am getting Out of Memory errors, how can I allocate more memory to FishEye?
Since the default memory setting usually is around 64MB or 128MB, you might have to adjust the settings to run a bigger FishEye instance with sufficient memory.
On this page:
Out Of Memory Errors
There are a number of different memory errors that the JVM will throw. The most common are listed as follows.
In the following, you will be required to set your memory settings via your FISHEYE_OPTS Environment Variables.
You will need to restart your server after setting your FISHEYE_OPTS.
After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.
OutOfMemoryError: Java Heap Space
|
If you are running Fisheye/Crucible as a windows service, increasing memory needs to be done in the wrapper.conf file. Refere to the Can Fisheye be run as a Windows Service for instructions. |
To solve this error, you will need to add the argument -Xmx1024m to FISHEYE_OPTS, in addition to any argument you use to set the heap size. Often you need to increase the amount of memory allocated to fisheye during the initial scan and period and once this is completed you can reduce back down.
FISHEYE_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=256m"
After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.
OutOfMemoryError: PermGen space, or Permanent Generation Size
If you get the error message: java.lang.OutOfMemoryError: PermGen space this means that you have exceeded Java's fixed 64MB block for loading class files. You will need to add the argument -XX:MaxPermSize=256m to FISHEYE_OPTS, in addition to any argument you use to set the heap size.
FISHEYE_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=256m"
After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.
OutOfMemoryError: unable to create new native thread
This error occurs when the operating system is unable to create new threads. This is due to the JVM Heap taking up the available RAM.
For Linux the maximum heap size of the JVM cannot be greater than 2GB. If you only have 2GB RAM in your server, it is not recommended to set the Max size of the JVM that high.Big heaps take away from the space that can be allocated for the stack of a new thread
The size of the stack per thread can also contribute to this problem. The stack size can reduce the number of threads that can be created.
To fix this problem, you should reduce the size of your JVM Heap and also the size of the stack per thread.
The stack size can be changed with the following (example) parameter being added to your FISHEYE_OPTS:
FISHEYE_OPTS="-Xms128m -Xmx1024m -XX:MaxPermSize=256m -Xss512k"
Please refer to this guide as a reference for JVM tuning.
After having set the FISHEYE_OPTS and restarting your server, go to Administration > Sys Info/Support > System Info, and check your JVM Input Arguments to ensure that your server is picking up your FISHEYE_OPTS as expected.
OutOfMemoryError: GC overhead limit exceeded
This error indicates that the JVM took too long to free up memory during its GC process. This error can be thrown from the Parallel or Concurrent collectors.
This kind of OutOfMemoryError can be caused if your java process is starting to use swapped memory for its heap. This will cause the JVM to take a lot longer than normal to perform normal GC operations. This can eventually cause a timeout to occur and cause this error.The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.
To overcome this issue, you need to make sure that all processes can't allocate more memory than there is system memory. In practice this is impossible to do for all processes. At a minimum you should make sure that all your jvm's do not have a total maximum memory allocation than your normally available system memory.
Please refer to this guide for more information.
java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
Essentially the native objects does not have enough memory to use. This is usually because you have allocated too much memory to your heap reducing the amount available for native objects. See this article.
The solution is to reduce the amount of heap memory you have allocated. For example if you have set -Xmx4096, you should consider reducing this to -Xmx2048m.
Remember if you are using a 32bit JVM you cannot allocate more than -Xmx2048m for linux (and even less for windows). Using a 64 bit JVM can resolve this problem, but is not recommended for fisheye/crucible instances (refer to System Requirements).
Read the Tuning FishEye page for more detail on adjusting resource limits and performance settings in FishEye.
婧愯嚜 錛?a >http://confluence.atlassian.com/display/FISHEYE/Fix+Out+of+Memory+errors+by+increasing+available+memory#FixOutofMemoryerrorsbyincreasingavailablememory-OutOfMemoryError%3Aunabletocreatenewnativethread,
I used to be able to open *.sql files in my Eclipse text editor. For some reason that stopped working this morning:
聽聽聽 Invalid menu handle.
聽聽聽 Problems opening an editor... unable to open external editor.
To fix this behavior for ALL files of a certain extension:
聽聽聽 Window > Preferences -
... and on the Preferences Tree:
聽聽聽 General > Editors > File Associations -
... add your File Type extension, for example *.sql
... and finally add your Associated Editor. I chose "internal editors" - "text editor"
You can also change the behavior "temporarily" for a single file. Right click the file, click "Open With..." and select the editor...
Why is serialization required?
In today's world, a typical enterprise application will have multiple components and will be distributed across various systems and networks. In Java, everything is represented as objects; if two Java components want to communicate with each other, there needs be a mechanism to exchange data. One way to achieve this is to define your own protocol and transfer an object. This means that the receiving end must know the protocol used by the sender to re-create the object, which would make it very difficult to talk to third-party components. Hence, there needs to be a generic and efficient protocol to transfer the object between components. Serialization is defined for this purpose, and Java components use this protocol to transfer objects.
Figure 1 shows a high-level view of client/server communication, where an object is transferred from the client to the server through serialization.
Figure 1. A high-level view of serialization in action (click to enlarge)
How to serialize an object
In order to serialize an object, you need to ensure that the class of the object implements the java.io.Serializable interface, as shown in Listing 1.
Listing 1. Implementing Serializable
import java.io.Serializable;
class TestSerial implements Serializable {
public byte version = 100;
public byte count = 0;
}
In Listing 1, the only thing you had to do differently from creating a normal class is implement the java.io.Serializable interface. The Serializable interface is a marker interface; it declares no methods at all. It tells the serialization mechanism that the class can be serialized.
Now that you have made the class eligible for serialization, the next step is to actually serialize the object. That is done by calling the writeObject() method of the java.io.ObjectOutputStream class, as shown in Listing 2.
Listing 2. Calling writeObject()
public static void main(String args[]) throws IOException {
FileOutputStream fos = new FileOutputStream("temp.out");
ObjectOutputStream oos = new ObjectOutputStream(fos);
TestSerial ts = new TestSerial();
oos.writeObject(ts);
oos.flush();
oos.close();
}
Listing 2 stores the state of the TestSerial object in a file called temp.out. oos.writeObject(ts); actually kicks off the serialization algorithm, which in turn writes the object to temp.out.
To re-create the object from the persistent file, you would employ the code in Listing 3.
Listing 3. Recreating a serialized object
public static void main(String args[]) throws IOException {
FileInputStream fis = new FileInputStream("temp.out");
ObjectInputStream oin = new ObjectInputStream(fis);
TestSerial ts = (TestSerial) oin.readObject();
System.out.println("version="+ts.version);
}
In Listing 3, the object's restoration occurs with the oin.readObject() method call. This method call reads in the raw bytes that we previously persisted and creates a live object that is an exact replica of the original object graph. Because readObject() can read any serializable object, a cast to the correct type is required.
Executing this code will print version=100 on the standard output.
The serialized format of an object
What does the serialized version of the object look like? Remember, the sample code in the previous section saved the serialized version of the TestSerial object into the file temp.out. Listing 4 shows the contents of temp.out, displayed in hexadecimal. (You need a hexadecimal editor to see the output in hexadecimal format.)
Listing 4. Hexadecimal form of TestSerial
AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 A0 0C 34 00 FE B1 DD F9 02 00 02 42 00 05
63 6F 75 6E 74 42 00 07 76 65 72 73 69 6F 6E 78
70 00 64
If you look again at the actual TestSerial object, you'll see that it has only two byte members, as shown in Listing 5.
Listing 5. TestSerial's byte members
public byte version = 100;
public byte count = 0;
The size of a byte variable is one byte, and hence the total size of the object (without the header) is two bytes. But if you look at the size of the serialized object in Listing 4, you'll see 51 bytes. Surprise! Where did the extra bytes come from, and what is their significance? They are introduced by the serialization algorithm, and are required in order to to re-create the object. In the next section, you'll explore this algorithm in detail.
Java's serialization algorithm
By now, you should have a pretty good knowledge of how to serialize an object. But how does the process work under the hood? In general the serialization algorithm does the following:
- It writes out the metadata of the class associated with an instance.
- It recursively writes out the description of the superclass until it finds
java.lang.object. - Once it finishes writing the metadata information, it then starts with the actual data associated with the instance. But this time, it starts from the topmost superclass.
- It recursively writes the data associated with the instance, starting from the least superclass to the most-derived class.
I've written a different example object for this section that will cover all possible cases. The new sample object to be serialized is shown in Listing 6.
Listing 6. Sample serialized object
class parent implements Serializable {
int parentVersion = 10;
}
class contain implements Serializable{
int containVersion = 11;
}
public class SerialTest extends parent implements Serializable {
int version = 66;
contain con = new contain();
public int getVersion() {
return version;
}
public static void main(String args[]) throws IOException {
FileOutputStream fos = new FileOutputStream("temp.out");
ObjectOutputStream oos = new ObjectOutputStream(fos);
SerialTest st = new SerialTest();
oos.writeObject(st);
oos.flush();
oos.close();
}
}
This example is a straightforward one. It serializes an object of type SerialTest, which is derived from parent and has a container object, contain. The serialized format of this object is shown in Listing 7.
Listing 7. Serialized form of sample object
AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 05 52 81 5A AC 66 02 F6 02 00 02 49 00 07
76 65 72 73 69 6F 6E 4C 00 03 63 6F 6E 74 00 09
4C 63 6F 6E 74 61 69 6E 3B 78 72 00 06 70 61 72
65 6E 74 0E DB D2 BD 85 EE 63 7A 02 00 01 49 00
0D 70 61 72 65 6E 74 56 65 72 73 69 6F 6E 78 70
00 00 00 0A 00 00 00 42 73 72 00 07 63 6F 6E 74
61 69 6E FC BB E6 0E FB CB 60 C7 02 00 01 49 00
0E 63 6F 6E 74 61 69 6E 56 65 72 73 69 6F 6E 78
70 00 00 00 0B
Figure 2 offers a high-level look at the serialization algorithm for this scenario.
Figure 2. An outline of the serialization algorithm
Let's go through the serialized format of the object in detail and see what each byte represents. Begin with the serialization protocol information:
-
AC ED:STREAM_MAGIC. Specifies that this is a serialization protocol. -
00 05:STREAM_VERSION. The serialization version. -
0x73:TC_OBJECT. Specifies that this is a newObject.
The first step of the serialization algorithm is to write the description of the class associated with an instance. The example serializes an object of type SerialTest, so the algorithm starts by writing the description of the SerialTest class.
-
0x72:TC_CLASSDESC. Specifies that this is a new class. -
00 0A: Length of the class name. -
53 65 72 69 61 6c 54 65 73 74:SerialTest, the name of the class. -
05 52 81 5A AC 66 02 F6:SerialVersionUID, the serial version identifier of this class. -
0x02: Various flags. This particular flag says that the object supports serialization. -
00 02: Number of fields in this class.
Next, the algorithm writes the field int version = 66;.
-
0x49: Field type code. 49 represents "I", which stands forInt. -
00 07: Length of the field name. -
76 65 72 73 69 6F 6E:version, the name of the field.
And then the algorithm writes the next field, contain con = new contain();. This is an object, so it will write the canonical JVM signature of this field.
-
0x74:TC_STRING. Represents a new string. -
00 09: Length of the string. -
4C 63 6F 6E 74 61 69 6E 3B:Lcontain;, the canonical JVM signature. -
0x78:TC_ENDBLOCKDATA, the end of the optional block data for an object.
The next step of the algorithm is to write the description of the parent class, which is the immediate superclass of SerialTest.
-
0x72:TC_CLASSDESC. Specifies that this is a new class. -
00 06: Length of the class name. -
70 61 72 65 6E 74:SerialTest, the name of the class -
0E DB D2 BD 85 EE 63 7A:SerialVersionUID, the serial version identifier of this class. -
0x02: Various flags. This flag notes that the object supports serialization. -
00 01: Number of fields in this class.
Now the algorithm will write the field description for the parent class. parent has one field, int parentVersion = 100;.
-
0x49: Field type code. 49 represents "I", which stands forInt. -
00 0D: Length of the field name. -
70 61 72 65 6E 74 56 65 72 73 69 6F 6E:parentVersion, the name of the field. -
0x78:TC_ENDBLOCKDATA, the end of block data for this object. -
0x70:TC_NULL, which represents the fact that there are no more superclasses because we have reached the top of the class hierarchy.
So far, the serialization algorithm has written the description of the class associated with the instance and all its superclasses. Next, it will write the actual data associated with the instance. It writes the parent class members first:
-
00 00 00 0A: 10, the value ofparentVersion.
Then it moves on to SerialTest.
-
00 00 00 42: 66, the value ofversion.
The next few bytes are interesting. The algorithm needs to write the information about the contain object, shown in Listing 8.
Listing 8. The contain object
contain con = new contain();
Remember, the serialization algorithm hasn't written the class description for the contain class yet. This is the opportunity to write this description.
-
0x73:TC_OBJECT, designating a new object. -
0x72:TC_CLASSDESC. -
00 07: Length of the class name. -
63 6F 6E 74 61 69 6E:contain, the name of the class. -
FC BB E6 0E FB CB 60 C7:SerialVersionUID, the serial version identifier of this class. -
0x02: Various flags. This flag indicates that this class supports serialization. -
00 01: Number of fields in this class.
Next, the algorithm must write the description for contain's only field, int containVersion = 11;.
-
0x49: Field type code. 49 represents "I", which stands forInt. -
00 0E: Length of the field name. -
63 6F 6E 74 61 69 6E 56 65 72 73 69 6F 6E:containVersion, the name of the field. -
0x78:TC_ENDBLOCKDATA.
Next, the serialization algorithm checks to see if contain has any parent classes. If it did, the algorithm would start writing that class; but in this case there is no superclass for contain, so the algorithm writes TC_NULL.
-
0x70:TC_NULL.
Finally, the algorithm writes the actual data associated with contain.
-
00 00 00 0B: 11, the value ofcontainVersion.
Conclusion
In this tip, you have seen how to serialize an object, and learned how the serialization algorithm works in detail. I hope this article gives you more detail on what happens when you actually serialize an object.
From 聽錛?http://www.javaworld.com/community/node/2915
x聽 聽 聽 聽 聽 聽y聽 聽 聽 聽 聽 聽 聽 聽 聽x&y聽
-----------------------------
0聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 0
0聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 0
1聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 0
1聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 1
Example on & operator
聽 聽 聽byte x = 50;
聽 聽 聽byte y = 51;
聽 聽 聽byte result = (byte) (x&y);
聽 聽 System.out.println("Result of x&y= : " + result );
The result equal = 50
00110010
00110011
-------------
00110010
2- The OR operator : (|)
x聽 聽 聽 聽 聽 聽y聽 聽 聽 聽 聽 聽 聽 聽 聽x|y聽
-----------------------------
0聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 0
0聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 1
1聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 1
1聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 1
Example on | operator
聽 聽 聽byte x = 50;
聽 聽 聽byte y = 51;
聽 聽 聽byte result = (byte) (x|y);
聽 聽 System.out.println("Result of x|y= : " + result );
The result equal = 51
00110010
00110011
-------------
00110011
3- The XOR operator : (^)
x聽 聽 聽 聽 聽 聽y聽 聽 聽 聽 聽 聽 聽 聽 聽x^y聽
-----------------------------
0聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 0
0聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 1
1聽 聽 聽 聽 聽 聽0聽 聽 聽 聽 聽 聽 聽 聽 聽 1
1聽 聽 聽 聽 聽 聽1聽 聽 聽 聽 聽 聽 聽 聽 聽 0
Example on ^ operator
聽 聽 聽byte x = 50;
聽 聽 聽byte y = 51;
聽 聽 聽byte result = (byte) (x^y);
聽 聽 System.out.println("Result of x^y= : " + result );
The result equal = 1
00110010
00110011
-------------
00000001
4- The Inversion Operator: (~)
Invert each bit in the byte .
Example :
5- Boolean Inversion Operator (!)
invert the value of boolean
The GC will send some sort of "finalize" message to the object and then set any weakly-referencing variables to null whenever it disposes of the referenced object. This allows "finalization" logic to be run before the object is disposed of (e.g., close a file if still open, commit any open transaction(s), etc.). Java 1.1 does not support weak references other than via an undocumented Ref class that is not supported under Netscape. Weak references arrived officially with JDK 1.2. Java has three kinds of weak references, called soft references, weak references, and phantom references, in order of increasing weakness.
Java has four orders of strength in holding onto Objects. In descending order from strongest to weakest they are:
- The JVM holds onto regular Objects until they are no longer reachable by either clients or any container. In other words Objects are garbage collected when there are no more live references to them. Dead references don鈥檛 count.
- Soft references can be deleted from a container if the clients are no longer referencing them and memory is tight.
- Weak references are automatically deleted from a container as soon clients stop referencing them.
- Phantom references point to objects that are already dead and have been finalised.
涓錛幝犅犅?ClassLoader鍩烘湰姒傚康
1錛嶤lassLoader鍒嗙被
綾昏杞藉櫒鏄敤鏉ユ妸綾?class)瑁呰澆榪汮VM鐨勩?br />JVM瑙勮寖瀹氫箟浜嗕袱縐嶇被鍨嬬殑綾昏杞藉櫒錛?strong>鍚姩鍐呰杞藉櫒(bootstrap)鍜岀敤鎴瘋嚜瀹氫箟瑁呰澆鍣?/strong>(user-defined class loader)銆?
JVM鍦ㄨ繍琛屾椂浼氫駭鐢熶笁涓狢lassLoader:Bootstrap聽ClassLoader銆丒xtension聽ClassLoader鍜孉ppClassLoader.Bootstrap鏄敤C++緙栧啓鐨勶紝鎴戜滑鍦↗ava涓湅涓嶅埌瀹?鏄痭ull,鏄疛VM鑷甫鐨勭被瑁呰澆鍣紝鐢ㄦ潵瑁呰澆鏍稿績綾誨簱錛屽java.lang.*絳夈?br />AppClassLoader鐨?/strong>Parent鏄?/strong>ExtClassLoader錛岃?/strong>ExtClassLoader鐨?/strong>Parent涓?/strong>Bootstrap聽ClassLoader銆?/strong>
聽
Java鎻愪緵浜嗘娊璞＄被ClassLoader錛屾墍鏈夌敤鎴瘋嚜瀹氫箟綾昏杞藉櫒閮藉疄渚嬪寲鑷?/strong>ClassLoader鐨勫瓙綾匯?/strong> System Class Loader鏄竴涓壒孌婄殑鐢ㄦ埛鑷畾涔夌被瑁呰澆鍣紝鐢?/strong>JVM鐨勫疄鐜拌呮彁渚涳紝鍦ㄧ紪紼嬭呬笉鐗瑰埆鎸囧畾瑁呰澆鍣ㄧ殑鎯呭喌涓嬮粯璁よ杞界敤鎴風被銆傜郴緇熺被瑁呰澆鍣ㄥ彲浠ラ氳繃ClassLoader.getSystemClassLoader() 鏂規硶寰楀埌銆?br />聽
渚?錛屾祴璇曚綘鎵浣跨敤鐨凧VM鐨凜lassLoader
/*LoaderSample1.java*/
聽聽聽聽public聽static聽void聽main(String[]聽args)聽{
聽聽聽聽聽聽聽聽Class聽c;
聽聽聽聽聽聽聽聽ClassLoader聽cl;
聽聽聽聽聽聽聽聽cl聽=聽ClassLoader.getSystemClassLoader();
聽聽聽聽聽聽聽聽System.out.println(cl);
聽聽聽聽聽聽聽聽while聽(cl聽!=聽null)聽{
聽聽聽聽聽聽聽聽聽聽聽聽cl聽=聽cl.getParent();
聽聽聽聽聽聽聽聽聽聽聽聽System.out.println(cl);
聽聽聽聽聽聽聽聽}
聽聽聽聽聽聽聽聽try聽{
聽聽聽聽聽聽聽聽聽聽聽聽c聽=聽Class.forName("java.lang.Object");
聽聽聽聽聽聽聽聽聽聽聽聽cl聽=聽c.getClassLoader();
聽聽聽聽聽聽聽聽聽聽聽聽System.out.println("java.lang.Object's聽loader聽is聽"聽+聽cl);
聽聽聽聽聽聽聽聽聽聽聽聽c聽=聽Class.forName("LoaderSample1");
聽聽聽聽聽聽聽聽聽聽聽聽cl聽=聽c.getClassLoader();
聽聽聽聽聽聽聽聽聽聽聽聽System.out.println("LoaderSample1's聽loader聽is聽"聽+聽cl);
聽聽聽聽聽聽聽聽}聽catch聽(Exception聽e)聽{
聽聽聽聽聽聽聽聽聽聽聽聽e.printStackTrace();
聽聽聽聽聽聽聽聽}
聽聽聽聽}
}
鍦ㄦ垜鐨勬満鍣ㄤ笂(Sun Java 1.4.2)鐨勮繍琛岀粨鏋?br />sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$ExtClassLoader@e2eec8
null
java.lang.Object's loader is null
LoaderSample1's loader is sun.misc.Launcher$AppClassLoader@1a0c10f
絎竴琛岃〃紺猴紝緋葷粺綾昏杞藉櫒瀹炰緥鍖栬嚜綾籹un.misc.Launcher$AppClassLoader
絎簩琛岃〃紺猴紝緋葷粺綾昏杞藉櫒鐨刾arent瀹炰緥鍖栬嚜綾籹un.misc.Launcher$ExtClassLoader
絎笁琛岃〃紺猴紝緋葷粺綾昏杞藉櫒parent鐨刾arent涓篵ootstrap
絎洓琛岃〃紺猴紝鏍稿績綾籮ava.lang.Object鏄敱bootstrap瑁呰澆鐨?
絎簲琛岃〃紺猴紝鐢ㄦ埛綾籐oaderSample1鏄敱緋葷粺綾昏杞藉櫒瑁呰澆鐨?
聽
聽
浜岋紟parent delegation妯″瀷
浠?.2鐗堟湰寮濮嬶紝Java寮曞叆浜嗗弻浜插鎵樻ā鍨嬶紝浠庤屾洿濂界殑淇濊瘉Java騫沖彴鐨勫畨鍏ㄣ?strong>鍦ㄦ妯″瀷涓嬶紝褰撲竴涓杞藉櫒琚姹傝杞芥煇涓被鏃訛紝瀹冮鍏堝鎵樿嚜宸辯殑
鍥?1 parent delegation妯″瀷
濡傚浘1鎵紺猴紝loader2鐨刾arent涓簂oader1錛宭oader1鐨刾arent涓簊ystem class loader銆傚亣璁緇oader2琚姹傝杞界被MyClass錛屽湪parent delegation妯″瀷涓嬶紝loader2棣栧厛璇鋒眰loader1浠ｄ負瑁呰澆錛宭oader1鍐嶈姹傜郴緇熺被瑁呰澆鍣ㄥ幓瑁呰澆MyClass銆傝嫢緋葷粺瑁呰澆鍣ㄨ兘鎴愬姛瑁呰澆錛屽垯灝哅yClass鎵瀵瑰簲鐨凜lass瀵硅薄鐨剅eference榪斿洖緇檒oader1錛宭oader1鍐嶅皢reference榪斿洖緇檒oader2錛屼粠鑰屾垚鍔熷皢綾籑yClass瑁呰澆榪涜櫄鎷熸満銆傝嫢緋葷粺綾昏杞藉櫒涓嶈兘瑁呰澆MyClass錛宭oader1浼氬皾璇曡杞組yClass錛岃嫢loader1涔熶笉鑳芥垚鍔熻杞斤紝loader2浼氬皾璇曡杞姐傝嫢鎵鏈夌殑parent鍙妉oader2鏈韓閮戒笉鑳借杞斤紝鍒欒杞藉け璐ャ?br />聽
鑻ユ湁涓涓兘鎴愬姛瑁呰澆錛屽疄闄呰杞界殑綾昏杞藉櫒琚О涓哄畾涔夌被瑁呰澆鍣紝鎵鏈夎兘鎴愬姛榪斿洖Class瀵硅薄鐨勮杞藉櫒錛堝寘鎷畾涔夌被瑁呰澆鍣級琚О涓哄垵濮嬬被瑁呰澆鍣ㄣ傚鍥?鎵紺猴紝鍋囪loader1瀹為檯瑁呰澆浜哅yClass錛屽垯loader1涓篗yClass鐨勫畾涔夌被瑁呰澆鍣紝loader2鍜宭oader1涓篗yClass鐨勫垵濮嬬被瑁呰澆鍣ㄣ?br />聽
闇瑕佹寚鍑虹殑鏄紝Class Loader鏄璞★紝瀹冪殑鐖跺瓙鍏崇郴鍜岀被鐨勭埗瀛愬叧緋繪病鏈変換浣曞叧緋匯?br />聽
閭ｄ箞parent delegation妯″瀷涓轟粈涔堟洿瀹夊叏浜嗭紵鍥犱負鍦ㄦ妯″瀷涓嬬敤鎴瘋嚜瀹氫箟鐨勭被瑁呰澆鍣ㄤ笉鍙兘瑁呰澆搴旇鐢辯埗浜茶杞藉櫒瑁呰澆鐨勫彲闈犵被錛屼粠鑰岄槻姝笉鍙潬鐢氳嚦鎭舵剰鐨勪唬鐮佷唬鏇跨敱鐖朵翰瑁呰澆鍣ㄨ杞界殑鍙潬浠ｇ爜銆傚疄闄呬笂錛岀被瑁呰澆鍣ㄧ殑緙栧啓鑰呭彲浠ヨ嚜鐢遍夋嫨涓嶇敤鎶婅姹傚鎵樼粰parent錛屼絾姝ｅ涓婃墍璇達紝浼氬甫鏉ュ畨鍏ㄧ殑闂銆?/strong>
聽
聽
涓夛紟鍛藉悕絀洪棿鍙婂叾浣滅敤
姣忎釜綾昏杞藉櫒鏈夎嚜宸辯殑鍛藉悕絀洪棿錛屽懡鍚嶇┖闂寸敱鎵鏈変互姝よ杞藉櫒涓哄垱濮嬬被瑁呰澆鍣ㄧ殑綾葷粍鎴愩備笉鍚屽懡鍚嶇┖闂寸殑涓や釜綾繪槸涓嶅彲瑙佺殑錛屼絾鍙寰楀埌綾繪墍瀵瑰簲鐨凜lass瀵硅薄鐨剅eference錛岃繕鏄彲浠ヨ闂彟涓鍛藉悕絀洪棿鐨勭被銆?br />聽
渚?婕旂ず浜嗕竴涓懡鍚嶇┖闂寸殑綾誨浣曚嬌鐢ㄥ彟涓鍛藉悕絀洪棿鐨勭被銆傚湪渚嬪瓙涓紝LoaderSample2鐢辯郴緇熺被瑁呰澆鍣ㄨ杞斤紝LoaderSample3鐢辮嚜瀹氫箟鐨勮杞藉櫒loader璐熻矗瑁呰澆錛屼袱涓被涓嶅湪鍚屼竴鍛藉悕絀洪棿錛屼絾LoaderSample2寰楀埌浜哃oaderSample3鎵瀵瑰簲鐨凜lass瀵硅薄鐨剅eference錛屾墍浠ュ畠鍙互璁塊棶LoaderSampl3涓叕鍏辯殑鎴愬憳(濡俛ge)銆?br />渚?涓嶅悓鍛藉悕絀洪棿鐨勭被鐨勮闂?br />/*LoaderSample2.java*/
import聽java.lang.reflect.*;
public聽class聽LoaderSample2聽{
聽聽聽聽public聽static聽void聽main(String[]聽args)聽{
聽聽聽聽聽聽聽聽try聽{
聽聽聽聽聽聽聽聽聽聽聽聽String聽path聽=聽System.getProperty("user.dir");
聽聽聽聽聽聽聽聽聽聽聽聽URL[]聽us聽=聽{new聽URL("file://"聽+聽path聽+聽"/sub/")};
聽聽聽聽聽聽聽聽聽聽聽聽ClassLoader聽loader聽=聽new聽URLClassLoader(us);
聽聽聽聽聽聽聽聽聽聽聽聽Class聽c聽=聽loader.loadClass("LoaderSample3");
聽聽聽聽聽聽聽聽聽聽聽聽Object聽o聽=聽c.newInstance();
聽聽聽聽聽聽聽聽聽聽聽聽Field聽f聽=聽c.getField("age");
聽聽聽聽聽聽聽聽聽聽聽聽int聽age聽=聽f.getInt(o);
聽聽聽聽聽聽聽聽聽聽聽聽System.out.println("age聽is聽"聽+聽age);
聽聽聽聽聽聽聽聽}聽catch聽(Exception聽e)聽{
聽聽聽聽聽聽聽聽聽聽聽聽e.printStackTrace();
聽聽聽聽聽聽聽聽}
聽聽聽聽}
}
/*sub/Loadersample3.java*/
聽聽聽聽static聽{
聽聽聽聽聽聽聽聽System.out.println("LoaderSample3聽loaded");
聽聽聽聽}
聽聽聽聽public聽int聽age聽=聽30;
}
緙栬瘧錛歫avac LoaderSample2.java; javac sub/LoaderSample3.java
榪愯錛歫ava LoaderSample2
LoaderSample3 loaded
age is 30
浠庤繍琛岀粨鏋滀腑鍙互鐪嬪嚭錛屽湪綾籐oaderSample2涓彲浠ュ垱寤哄浜庡彟涓鍛藉悕絀洪棿鐨勭被LoaderSample3涓殑瀵硅薄騫跺彲浠ヨ闂叾鍏叡鎴愬憳age銆?br />榪愯鏃跺寘(runtime package)
鐢卞悓涓綾昏杞藉櫒瀹氫箟瑁呰澆鐨勫睘浜庣浉鍚屽寘鐨勭被緇勬垚浜嗚繍琛屾椂鍖咃紝鍐沖畾涓や釜綾繪槸涓嶆槸灞炰簬鍚屼竴涓繍琛屾椂鍖咃紝涓嶄粎瑕佺湅瀹冧滑鐨勫寘鍚嶆槸鍚︾浉鍚岋紝榪樿鐪嬬殑瀹氫箟綾昏杞藉櫒鏄惁鐩稿悓銆傚彧鏈夊睘浜庡悓涓榪愯鏃跺寘鐨勭被鎵嶈兘浜掔浉璁塊棶鍖呭彲瑙佺殑綾誨拰鎴愬憳銆傝繖鏍風殑闄愬埗閬垮厤浜嗙敤鎴瘋嚜宸辯殑浠ｇ爜鍐掑厖鏍稿績綾誨簱鐨勭被璁塊棶鏍稿績綾誨簱鍖呭彲瑙佹垚鍛樼殑鎯呭喌銆傚亣璁劇敤鎴瘋嚜宸卞畾涔変簡涓涓被java.lang.Yes錛屽茍鐢ㄧ敤鎴瘋嚜瀹氫箟鐨勭被瑁呰澆鍣ㄨ杞斤紝鐢變簬java.lang.Yes鍜屾牳蹇冪被搴搄ava.lang.*鐢變笉鍚岀殑瑁呰澆鍣ㄨ杞斤紝瀹冧滑灞炰簬涓嶅悓鐨勮繍琛屾椂鍖咃紝鎵浠ava.lang.Yes涓嶈兘璁塊棶鏍稿績綾誨簱java.lang涓被鐨勫寘鍙鐨勬垚鍛樸?
聽
鎬葷粨
鍛藉悕絀洪棿騫舵病鏈夊畬鍏ㄧ姝㈠睘浜庝笉鍚岀┖闂寸殑綾葷殑浜掔浉璁塊棶錛屽弻浜插鎵樻ā鍨嬪姞寮轟簡Java鐨勫畨鍏紝榪愯鏃跺寘澧炲姞浜嗗鍖呭彲瑙佹垚鍛樼殑淇濇姢銆?/strong>
聽
浜岋紟聽聽聽 鎵╁睍ClassLoader鏂規硶
鎴戜滑鐩殑鏄粠鏈湴鏂囦歡緋葷粺浣跨敤鎴戜滑瀹炵幇鐨勭被瑁呰澆鍣ㄨ杞戒竴涓被銆?strong>涓轟簡鍒涘緩鑷繁鐨勭被瑁呰澆鍣ㄦ垜浠簲璇ユ墿灞?/strong>ClassLoader綾伙紝榪欐槸涓涓娊璞＄被銆傛垜浠垱寤轟竴涓?/strong>FileClassLoader extends ClassLoader銆傛垜浠渶瑕佽鐩?/strong>ClassLoader涓殑findClass(String name)鏂規硶錛岃繖涓柟娉曢氳繃綾葷殑鍚嶅瓧鑰屽緱鍒頒竴涓?/strong>Class瀵硅薄銆?/strong>
聽聽聽聽{
聽聽聽聽聽聽聽聽byte[]聽data聽=聽loadClassData(name);
聽聽聽聽聽聽聽聽return聽defineClass(name,聽data,聽0,聽data.length);
聽聽聽聽}
聽聽聽鎴戜滑榪樺簲璇ユ彁渚涗竴涓柟娉昹oadClassData(String name)錛岄氳繃綾葷殑鍚嶇О榪斿洖class鏂囦歡鐨勫瓧
鑺傛暟緇勩傜劧鍚庝嬌鐢–lassLoader鎻愪緵鐨刣efineClass()鏂規硶鎴戜滑灝卞彲浠ヨ繑鍥濩lass瀵硅薄浜嗐?/strong>
聽聽聽聽{
聽聽聽聽聽聽聽聽FileInputStream聽fis聽=聽null;
聽聽聽聽聽聽聽聽byte[]聽data聽=聽null;
聽聽聽聽聽聽聽聽try
聽聽聽聽聽聽聽聽{
聽聽聽聽聽聽聽聽聽聽聽聽fis聽=聽new聽FileInputStream(new聽File(drive聽+聽name聽+聽fileType));
聽聽聽聽聽聽聽聽聽聽聽聽ByteArrayOutputStream聽baos聽=聽new聽ByteArrayOutputStream();
聽聽聽聽聽聽聽聽聽聽聽聽int聽ch聽=聽0;
聽聽聽聽聽聽聽聽聽聽聽聽while聽((ch聽=聽fis.read())聽!=聽-1)
聽聽聽聽聽聽聽聽聽聽聽聽{
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽baos.write(ch);
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽
聽聽聽聽聽聽聽聽聽聽聽聽}
聽聽聽聽聽聽聽聽聽聽聽聽data聽=聽baos.toByteArray();
聽聽聽聽聽聽聽聽}聽catch聽(IOException聽e)
聽聽聽聽聽聽聽聽{
聽聽聽聽聽聽聽聽聽聽聽聽e.printStackTrace();
聽聽聽聽聽聽聽聽}
聽聽聽聽聽聽聽聽
聽聽聽聽聽聽聽聽return聽data;
聽聽聽聽}
鍐嶈璇碢ackage鏉冮檺銆侸ava璇█瑙勫畾錛屽湪鍚屼竴涓寘涓殑class錛屽鏋滄病鏈変慨楗扮錛岄粯璁や負Package鏉冮檺錛屽寘鍐呯殑class閮藉彲浠ヨ闂備絾鏄繖榪樹笉澶熷噯紜傜‘鍒囩殑璇達紝鍙湁鐢卞悓涓涓狢lassLoader瑁呰澆鐨刢lass鎵嶅叿鏈変互涓婄殑Package鏉冮檺銆傛瘮濡傚惎鍔ㄧ被瑁呰澆鍣ㄨ杞戒簡java.lang.String錛岀被璺緞瑁呰澆鍣ㄨ杞戒簡鎴戜滑鑷繁鍐欑殑java.lang.Test錛屽畠浠笉鑳戒簰鐩歌闂鏂瑰叿鏈塒ackage鏉冮檺鐨勬柟娉曘傝繖鏍峰氨闃繪浜嗘伓鎰忎唬鐮佽闂牳蹇冪被鐨凱ackage鏉冮檺鏂規硶銆?/font>
The Java programming language also provides operators that perform bitwise and bit shift operations on integral types. The operators discussed in this section are less commonly used. Therefore, their coverage is brief; the intent is to simply make you aware that these operators exist.The unary bitwise complement operator "
~" inverts a bit pattern; it can be applied to any of the integral types, making every "0" a "1" and every "1" a "0". For example, abytecontains 8 bits; applying this operator to a value whose bit pattern is "00000000" would change its pattern to "11111111".The signed left shift operator "
<<" shifts a bit pattern to the left, and the signed right shift operator ">>" shifts a bit pattern to the right. The bit pattern is given by the left-hand operand, and the number of positions to shift by the right-hand operand. The unsigned right shift operator ">>>" shifts a zero into the leftmost position, while the leftmost position after">>"depends on sign extension.The bitwise
&operator performs a bitwise AND operation.The bitwise
^operator performs a bitwise exclusive OR operation.The bitwise
|operator performs a bitwise inclusive OR operation.The following program,
BitDemo, uses the bitwise AND operator to print the number "2" to standard output.class BitDemo { public static void main(String[] args) { int bitmask = 0x000F; int val = 0x2222; System.out.println(val & bitmask); // prints "2" }
very weird and unexpected. The following is the context of the Javadoc for Process.
In effect, you should be very clear of this limitation before you think of using
the Process JDK. Ok, here it is:
The methods that create processes may not work well for special processes on certain
native platforms, such as native windowing processes, daemon processes, Win16/DOS
processes on Microsoft Windows, or shell scripts.
The created subprocess does not have its own terminal or console. All its standard
io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process
through three streams (getOutputStream(), getInputStream(), getErrorStream()).
...
So basically, Process does not guarantee your daemon process to work properly. This
is horrifying when I first read about this Javadoc. However, I have changed my
mind after using Process for a while. My experience tells me that usually Process
cannot be working at the following circumstances: (assuming we are in Linux O.S.)
- to execute shell built-in commands e.g. "cd" or "alias"
- to redirect output from the executed application,
- This method will NOT expand filesystem wildcards e.g. "*".
Taking all these things into consideration, let's see what we can do to improve
your code.
First of all, Process has its standard outputstream, and its standard errorstream
(but don't try to redirect them, as it will *not* work)
Process proc = Runtime.getRuntime().exec(command);
// Create thread for reading inputStream (process' stdout)
proc.getInputStream();
// Create thread for reading errorStream (process' stderr)
proc.getErrorStream()
Another fact I can see why your ntpd has not stopped is maybe you havn't given
enough time for the Process to be executed completely.
Consider adding the following code into your program:
// this will wait for the process to end!!! I think it is very important
// not to interfere with other process in the O.S.
int returnCode = proc.waitFor();
String msg = "Shell command [" + commandString + "] result [";
if (returnCode == 0)
{
msg += "SUCCEEDED";
}
else
{
msg = msg + "FAILED - ret code: " + returnCode;
}
msg += "]";
Then you can print the msg to the standard output or simply trace it into your log.
You shall see the error if occurs.
Another thing I can suggest you to do is fully read the Process Javadoc and any related documents about using Process.
Hope these help.
import java.io.*;
public chass shell{
public static void main(String [] args)throws Exception{
try
{
process = Runtime.getRuntime().exec ("bin/sh service ntpd stop");
InputStreamReader ir=newInputStreamReader(process.getInputStream());
LineNumberReader input = new LineNumberReader (ir);
String line;
while ((line = input.readLine ()) != null)
System.out.println(line);
}
catch (java.io.IOException e){
System.err.println ("IOException " + e.getMessage());
}
}
聽
鏉ヨ嚜 :http://www.cjsdn.net/post/view?bid=1&id=196586