Jvm And Java Tunning

* In Java, a developer does not need to explicitly allocate and deallocate memory – the JVM and more specifically the Garbage Collector – has the duty of handling memory allocation so that the developer doesn’t have to.

* Garbage collection is the process of looking at heap memory, identifying which objects are in use and which are not, and deleting the unused objects.
* An in-use object, or a referenced object, means that some part of your program still maintains a pointer to that object.

* Whenever the garbage collector runs, it has an effect on the application’s performance.
* All other threads in the application have to be stopped to allow the garbage collector thread to effectively do its work.

* When the garbage collector thread is running, other threads are stopped, meaning the application is stopped momentarily.
* Depending on the needs of an application, "stop the world" garbage collection can cause an unacceptable freeze.

* The stack is a part of memory that contains information about the nested method calls down to the current position in the program.
* Contains all local variables and references to objects on the heap defined in currently executing methods.
* This structure allows the runtime to return from the method knowing the address whence it was called, and also clear all local variables after exiting the method.
* Every thread has its own stack.
* The heap is a large bulk of memory intended for the allocation of objects.
* When you create an object with the new keyword, it gets allocated on the heap.
* However, the reference to this object lives on the stack.

* Generational garbage collection can be loosely defined as the strategy used by the garbage collector.
* The heap is divided into a number of sections called generations, each of which will hold objects according to their "age" on the heap.
* The first step in the garbage collecting process is called marking.
* This is where the garbage collector identifies which pieces of memory are in use and which are not.
* This can be a very time-consuming process if all objects in a system must be scanned.
* Objects are grouped according to their "age" in terms of how many garbage collection cycles they have survived.
* This way, the bulk of the work is spread across various minor and major collection cycles.
* Empirical analysis of applications has shown that most objects are short-lived.

* The heap is divided up into Young Generation, Old or Tenured Generation, and Permanent Generation.
* The young generation hosts most of the newly created objects.
* Most applications show that majority of objects are quickly short-lived and therefore, soon become eligible for collection. High infant mortality rate.
* The term "age" in generational garbage collection refers to the number of collection cycles the object has survived.
* The young generation space is further divided into three spaces: an Eden space and two survivor spaces such as Survivor 1 (s1) and Survivor 2 (s2).
* The garbage collection is more expensive and occurs less frequently in the old generation.
* PermGen (permanent generation), contains metadata required by the JVM to describe the classes and methods used in the application.
* Platform library classes and methods may be stored here.
* Any new objects are allocated to the Eden space.
* When the Eden space fills up, a minor garbage collection is triggered.

* Referenced objects are moved to the first survivor space S0. Unreferenced objects are deleted.
* Referenced objects are moved to a survivor space again on the next minor GC, this time S1.
* Next minor GC, referenced objects are moved to S0 from both Eden and S1. Surviving objects are aged. Eden and S1 are cleared.
* Those that have reached a certain arbitrary age, are promoted from the young generation to the old or tenured generation.
* Eventually, a major garbage collection will be performed on the old generation which cleans up and compacts that space.
* For each major GC, there are several minor GCs.

* If that object is not reachable from any live threads or by any static references.
* Cyclic dependencies without any live external reference are also eligible for GC.
* If object A references object B and object B references Object A and they don't have any other live reference then both Objects A and B will be eligible for Garbage collection.
* When a parent object is set to null.

* As a Java programmer, can not force garbage collection in Java, it will only trigger if JVM thinks it needs a garbage collection based on Java heap size.
* Methods like System.gc() and Runtime.gc() are used to send requests for Garbage collection to JVM but it’s not guaranteed that garbage collection will happen.

Java Virtual Machine throws OutOfMemoryError or more specifically java.lang.OutOfMemoryError heap space.

* When an object becomes eligible for garbage collection, the GC has to run the finalize method on it.
* In the finalize method you can technically "resurrect" an object, for example, by assigning it to a static field.
* The object would become alive again and non-eligible for garbage collection.
* The object, however, would be marked as finalized, so when it would become eligible again, the finalize method would not be called.

* It is impossible to explicitly control when garbage collection is triggered.
* It is possible to influence how it occurs as regards the objects we have created.
* Strong Reference: The new keyword creates a new object and stores it on the heap. The variable then stores a strong reference to this object.
- This object is not eligible for collection at all due to a strong reference held to it by the variable.
- When nulling the object, the object will then be eligible for collection.
* Soft Reference: Through SoftReference<classType> allows the garbage collector will postpone collecting it.
- Objects with only soft references are collected as a last resort to recover memory.
* Weak Reference: Objects do not prevent their referents from being made finalizable, finalized, and then reclaimed.
* Phantom Reference: Used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism.

* Yes, a pair of objects with a circular reference can become eligible for garbage collection.
* GC checks if they are reachable by navigating the object graph starting from some garbage collection root.

* A String instance in Java is an object with two fields: a char[] value field and an int hash field.
* The hash field is calculated during the first hashCode() call and cached ever since.

* StringBuilder allows manipulating character sequences by appending, deleting, and inserting characters and strings.
* This is a mutable data structure, as opposed to the String class which is immutable.
* When concatenating two String instances, a new object is created, and strings are copied.
* StringBuilder allows handling string manipulations much more efficiently.
* StringBuffer is different from StringBuilder in that it is thread-safe.
* If you need to manipulate a string in a single thread, use StringBuilder instead.

* Serial GC -> It goes through all of the objects and marks which objects are available for GC, before clearing them out and then copying all of the objects into contiguous space.
* Parallel GC -> Similar to Serial, except that it uses multiple threads to perform the GC so should be faster.
* Concurrent Mark Sweep -> Minimizes pauses by doing most of the GC-related work concurrently with the processing of the application. MS is a non-compacting algorithm that can lead to fragmentation problems.
* G1GC -> garbage first garbage collector, a concurrent parallel collector that is viewed as the long-term replacement for CMS and does not suffer from the same fragmentation problems as CMS.

* It depends entirely on the application.
* Each one is tailored to the requirements of the application.
* Serial is better if you’re on a single CPU, or in a scenario where there are more VMs running on the machine than CPUs.
* Parallel is a throughput collector and really good if you have a lot of work to do but you’re ok with pauses.
* CMS is the best of the three if you need consistent responsiveness with minimal pauses.

* -XX:-UseConcMarkSweepGC: Use the CMS collector for the old gen.
* -XX:-UseParallelGC: Use Parallel GC for New Gen
* -XX:-UseParallelOldGC: Use Parallel GC for Old and New Gen.
* -XX:-HeapDumpOnOutOfMemoryError: Create a thread dump when the application runs out of memory. Very useful for diagnostics.
* -XX:-PrintGCDetails: Log out details of Garbage Collection.
* -Xms512m: Sets the initial heap size to 512m
* -Xmx1024m: Sets the maximum heap size to 1024m
* -XX:NewSize and -XX:MaxNewSize: Specifically set the default and max size of the New Generation
* -XX:NewRatio=3: Set the size of the Young Generation as a ratio of the size of the Old Generation.
* -XX:SurvivorRatio=10: Set the size of Eden space relative to the size of a survivor space.

* They are loaded at runtime when the respective Class is loaded.

* String pool (String intern pool) is a special storage area in the Java heap.

-> String s = new String("abc");
* Two objects will be created here. One object creates on memory in heap with a new operator and second in stack constant pool with "abc".

* Stack Segment -> Contains local variables and Reference variables(variables that hold the address of an object in the heap).
* Heap Segment -> Contains all created objects in runtime, objects only plus their object attributes (instance variables).
* Code Segment -> The segment where the actual compiled Java bytecodes reside when loaded.

* Code segment.

* Garbage collection does not guarantee that a program will not run out of memory.
* It is possible for programs to use up memory resources faster than they are garbage collected.
* It is also possible for programs to create objects that are not subject to garbage collection.

* Memory is allocated from the heap to hold all instance variables and implementation-specific data of the object and its superclasses.
* Implementation-specific data includes pointers to class and method data.
* The instance variables of the objects are initialized to their default values.
* The constructor for the most derived class is invoked.
* The first thing a constructor does is call the constructor for its superclasses.
* This process continues until the constructor for java.lang.Object is called.
* Before the body of the constructor is executed, all instance variable initializers and initialization blocks are executed.
* Then the body of the constructor is executed.
* Thus, the constructor for the base class completes first and the constructor for the most derived class completes last.

* Neither compiler nor JVM complains will complain about it. And the JVM will internally load the class only once no matter how many times you import the same class.

* Class, Heap, Stack, Register, Native Method Stack.

* Heap memory is used by all the parts of the application whereas stack memory is used only by one thread of execution.
* Whenever an object is created, it's always stored in the Heap space and stack memory contains the reference to it.
* Stack memory only contains local primitive variables and reference variables to objects in heap space.
* Objects stored in the heap are globally accessible whereas stack memory can't be accessed by other threads.
* Memory management in the stack is done in a LIFO manner whereas it's more complex in Heap memory because it's used globally.
* Heap memory is divided into Young-Generation, Old-Generation, etc.
* Stack memory is short-lived whereas heap memory lives from the start till the end of application execution.
* We can use -Xms and -Xmx JVM options to define the startup size and maximum size of heap memory.
* We can use -Xss to define the stack memory size.
* When stack memory is full, Java runtime throws java.lang.Stack

* Part of JVM which is used to load classes and interfaces.
* Application class loader -> An application or system class loader loads our own files in the classpath.
* Extension class loader -> Extension class loaders load classes that are an extension of the standard core Java classes.
* Bootstrap class loader -> A bootstrap or primordial class loader is the parent of all the others. The bootstrap class loader is written in native code, not Java – so it doesn't show up as a Java class.

* Class loaders follow the delegation model where on request to find a class or resource.
* A ClassLoader instance will delegate the search of the class or resource to the parent class loader.
* Extension -> Application -> Bootstrap -> ClassNotFoundError

* This Error is thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

* It's an interpreter.

* loadClass only loads the class but doesn't initialize the object whereas Class.forName initialize the object after loading it.

-Bytecode streams for each method, which are stored in the method area of the JVM
-Bytecode streams are a sequence of instructions for the JVM
-Instructions consist of an on-byte opCode followed by 0 or more operands
-The opCode means Operation code, which is the action to take
-If the JVM determines that more information is needed before taking actions the info is encoded into one or more operands that follow the opCode
-Each opCode disassembly into mnemonics (pattern aimed to assist in remembering things), which are aligned on one-byte boundaries
-Bytecode operates in the stack (pushing and popping).
-Primitive datatypes appears as operands
-More than one-byte primitive values, uses big-endian notation
- Opcodes iload, lload, fload, and dload push local variables of type int, long, float, and double, respectively, onto the stack
-Java byte stack wide is 32 bits
-Constant is implicit in the operation (iconst_0 -> integer constant 0), follows the opcode in the bytecode as operand () or