- Polymorphism
- the ability of a variable, function, or object to take multiple forms
- to define one interface with multiple implementations
- compile-time: - using the same method name, but different signature
- run-time: - using a reference type to control which method is called
@OverrideAnnodation- Runtime polymorphism
- Java determins which version super/sub class method to execute based on reference type of call
- used for readability and to ensure correct method is overriden
- Reflection
- Allows runtime inspection of objects to manipulate properties, etc
- Example: get all methods declared/annotated with
@Test - Example: only serialize fields that state with
external
volatileKeyword- used to indicate that a variables value maybe modified by multiple Threads simultaneously
- ensures that the variables value is always read from and written to the main memory, rather than being cached in a Threads local memory
- ensure visibility across all Threads
- Encapsulation
- used to protect references
- used to force access to be read-only / immutable
- Example: getters and setters
- Composition
- promotes code re-use: access control, loosely coupled, dependency injection
- easier to test with substitute or initialize
- a popular method for dependency injection
- Inheritance
- Properties and methods of one Class are passed to a dependent Class
- used to reduce code redundancy with a child / parent relationship
- used to isolate dependency
- Thread
- runs as part of a process
- can share resources with other Threads under the same process
- can run code concurrently run by another Thread
- Process
- Isolated resources for program execution
- Operating System can run many isolated Processes at the same time, which are considered programs
- Deadlock
- when one or more concurrent systems cannot make progress until the other resource is released (a circular dependency)
- solution: redesign the system without circular dependency Zombie
- when a process ends via
exitbefore the child process ends and its entry is removed from the process table - solution: parent process to
waitforexitstatus before ending Race Conditions - inconsistent retrievals - when a transaction reads some data before another transaction has finished modification
- dirty read / uncommitted data - when a transaction rollsback but the data is still used by another concurrent transaction
- lost update - when 2 or more transactions update at the same time then data is lost (clobbered)
Beginning with the J2SE 1.2, the virtual machine incorporated a number of different garbage collection algorithms that are combined using generational collection. While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to minimize the work required to reclaim unused ("garbage") objects. The most important of these observed properties is the weak generational hypothesis, which states that most objects survive for only a short period of time. [1]
Some objects do live longer, and so the distribution stretches out to the the right. For instance, there are typically some objects allocated at initialization that live until the process exits. Between these two extremes are objects that live for the duration of some intermediate computation, seen here as the lump to the right of the initial peak. Some applications have very different looking distributions, but a surprisingly large number possess this general shape. Efficient collection is made possible by focusing on the fact that a majority of objects "die young." [1]
To optimize for this scenario, memory is managed in generations, or memory pools holding objects of different ages. Garbage collection occurs in each generation when the generation fills up. The vast majority of objects are allocated in a pool dedicated to young objects (the young generation), and most objects die there. When the young generation fills up it causes a minor collection in which only the young generation is collected; garbage in other generations is not reclaimed. Minor collections can be optimized assuming the weak generational hypothesis holds and most objects in the young generation are garbage and can be reclaimed. The costs of such collections are, to the first order, proportional to the number of live objects being collected; a young generation full of dead objects is collected very quickly. Typically some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection. Eventually, the tenured generation will fill up and must be collected, resulting in a major collection, in which the entire heap is collected. Major collections usually last much longer than minor collections because a significantly larger number of objects are involved. [1]
A feature referred to here as ergonomics was introduced in J2SE 5.0. The goal of ergonomics is to provide good performance with little or no tuning of command line options by selecting the
- garbage collector,
- heap size,
- and runtime compiler at JVM startup, instead of using fixed defaults.
To optimize for this scenario, memory is managed in generations, or memory pools holding objects of different ages.
The vast majority of objects are allocated in a pool dedicated to young objects (the young generation), and most objects die there.
The costs of such collections are, to the first order, proportional to the number of live objects being collected; a young generation full of dead objects is collected very quickly.
When the young generation fills up it causes a minor collection in which only the young generation is collected; garbage in other generations is not reclaimed. Minor collections can be optimized assuming the weak generational hypothesis holds and most objects in the young generation are garbage and can be reclaimed.
Typically some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection.
Eventually, the tenured generation will fill up and must be collected, resulting in a major collection, in which the entire heap is collected.
Major collections usually last much longer than minor collections because a significantly larger number of objects are involved.
Throughput is the percentage of total time not spent in garbage collection, considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed).
Pauses are the times when an application appears unresponsive because garbage collection is occurring.