别听楼上的瞎说 得不到内存地址那个hashCode你都可以自己override，就是一个数字，输出了类似@xxxx这样的方式而已Another safety feature built into the Java Virtual Machine--one that serves as a backup to structured memory access--is the unspecified manner in which the runtime data areas are laid out inside the Java Virtual Machine. The runtime data areas are the memory areas in which the Java Virtual Machine stores the data it needs to execute a Java application: Java stacks (one for each thread), a method area, where bytecodes are stored, and a garbage-collected heap, where the objects created by the running program are stored. If you peer into a class file, you wonít find any memory addresses. When the Java Virtual Machine loads a class file, it decides where in its internal memory to put the bytecodes and other data it parses from the class file. When the Java Virtual Machine starts a thread, it decides where to put the Java stack it creates for the thread. When it creates a new object, it decides where in memory to put the object. Thus, a cracker cannot predict by looking at a class file where in memory the data representing that class, or objects instantiated from that class, will be kept. Whatís worse (for the cracker) is the cracker canít tell anything about memory layout by reading the Java Virtual Machine specification either. The manner in which a Java Virtual Machine lays out its internal data is not part of the specification. The designers of each Java Virtual Machine implementation decide which data structures their implementation will use to represent the runtime data areas, and where in memory their implementation will place them. As a result, even if a cracker were somehow able to break through the Java Virtual Machineís memory access restrictions, they would next be faced with the difficult task of finding something to subvert by looking around.
Another safety feature built into the Java Virtual Machine--one that serves as a backup to structured memory access--is the unspecified manner in which the runtime data areas are laid out inside the Java Virtual Machine. The runtime data areas are the memory areas in which the Java Virtual Machine stores the data it needs to execute a Java application: Java stacks (one for each thread), a method area, where bytecodes are stored, and a garbage-collected heap, where the objects created by the running program are stored. If you peer into a class file, you wonít find any memory addresses. When the Java Virtual Machine loads a class file, it decides where in its internal memory to put the bytecodes and other data it parses from the class file. When the Java Virtual Machine starts a thread, it decides where to put the Java stack it creates for the thread. When it creates a new object, it decides where in memory to put the object. Thus, a cracker cannot predict by looking at a class file where in memory the data representing that class, or objects instantiated from that class, will be kept. Whatís worse (for the cracker) is the cracker canít tell anything about memory layout by reading the Java Virtual Machine specification either. The manner in which a Java Virtual Machine lays out its internal data is not part of the specification. The designers of each Java Virtual Machine implementation decide which data structures their implementation will use to represent the runtime data areas, and where in memory their implementation will place them. As a result, even if a cracker were somehow able to break through the Java Virtual Machineís memory access restrictions, they would next be faced with the difficult task of finding something to subvert by looking around.
{
private static String staticObject = "a";
private String memberObject;
public Memory() { memberObject = "b"; }
public static void main(String[] args)
{
Memory test = new Memory();
System.out.println("newObject: "+test.hashCode());
System.out.println("staticVariable: "+Integer.valueOf(staticObject.hashCode()));
System.out.println("memberVariable: "+Integer.valueOf(test.memberObject.hashCode()));
if(true) {
String temp = "c";
System.out.println("tempObject: "+Integer.valueOf(temp.hashCode()));
}
String newVariable = new String("newVariable");
System.out.println("newVariable: "+Integer.valueOf(newVariable.hashCode()));
}
}---------- Java运行 ----------
newObject: 14576877
staticVariable: 97
memberVariable: 98
tempObject: 99
newVariable: 7159868可见，静态对象、成员对象和局部对象是连续存放的，地址很低。new的类存放在堆中，地址很高。另外，int之类的基本数据类型不是对象，没有hashCode（）方法。
得不到内存地址那个hashCode你都可以自己override，就是一个数字，输出了类似@xxxx这样的方式而已Another safety feature built into the Java Virtual Machine--one that serves as a backup to structured memory access--is the unspecified manner in which the runtime data areas are laid out inside the Java Virtual Machine. The runtime data areas are the memory areas in which the Java Virtual Machine stores the data it needs to execute a Java application: Java stacks (one for each thread), a method area, where bytecodes are stored, and a garbage-collected heap, where the objects created by the running program are stored. If you peer into a class file, you wonít find any memory addresses. When the Java Virtual Machine loads a class file, it decides where in its internal memory to put the bytecodes and other data it parses from the class file. When the Java Virtual Machine starts a thread, it decides where to put the Java stack it creates for the thread. When it creates a new object, it decides where in memory to put the object. Thus, a cracker cannot predict by looking at a class file where in memory the data representing that class, or objects instantiated from that class, will be kept. Whatís worse (for the cracker) is the cracker canít tell anything about memory layout by reading the Java Virtual Machine specification either. The manner in which a Java Virtual Machine lays out its internal data is not part of the specification. The designers of each Java Virtual Machine implementation decide which data structures their implementation will use to represent the runtime data areas, and where in memory their implementation will place them. As a result, even if a cracker were somehow able to break through the Java Virtual Machineís memory access restrictions, they would next be faced with the difficult task of finding something to subvert by looking around.