Java statistics primitives, objects, methods, and heaps (memory management and best practices)

OK, so I've been developing Java for more than a year and I'm trying to understand the language and best practices

So that's what I know:

>Java "by type" – this is a primitive for copies passed through copies and object references that point to their objects on the heap. > Original instance variables and references live in class objects in the heap, and local primitives and references live on the stack (in their respective stack frames). > The memory space created by perm is where the class metadata is stored (for reflection). > There is a space in the garden of Eden. The new object is a place, a young space. The objects existing in GC are preserved, and there is an eternal space for long-lived objects

So here's what I want to understand:

>Where are the static and static final primitives and reference activities? The JVM can use a single instance? > Static and static end objects are stored in the heap (I think they are moved for life)? > What is the best practice for the number of static final references in an application? > Creating more static final references will reduce the amount of heap space in the JVM?

I have read many different explanations (all different). If an experienced veteran of the Java language can provide a good explanation, I will like it very much Thank you in advance!

Solution

The young space includes Eden and survivor space

It is not defined, but in the sun / Oracle JVM, static fields live in special objects of class fields Each class loader has an instance, so static fields can have multiple instances

In their sun / Oracle Java 7 They may be in permgan or anywhere else

Keep them to a minimum

If you can change the final field to a static final field, you can save some space (if there are multiple instances) However, clarity is often more important than performance (I'll do this for clarity)

BTW: I have been developing Java for 13 years

They are independent. Each class loader can load its own version of the class (the code is not necessarily the same), and each class has its own static fields (they are not necessarily the same)

No,

No Some data not defined in a location may be anywhere, depending on the implementation and version

It is part of the old generation = permanent perm

Young = Eden survivor space * 2

The maximum heap size limits the total lifetime of young people Second generation and direct memory have their own limitations Memory mapped file completion follows any of these limitations

This is correct for the default parallel collector and concurrent tag scanning

The G1 collector does not divide spaces in the same way

Link for more details

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Java heap terminology: young,old and permanent generations?

http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html