...
Anchor |
---|
| class variable |
---|
| class variable |
---|
|
class variable : A class variable is a static
field associated with the containing class.
Anchor |
---|
condition predicate | condition predicate | Wiki Markup |
---|
*conditionclass predicatevariable* : "A conditionclass predicatevariable is ana expressionfield constructeddeclared fromusing the state variables ofkeyword {{static}} within a class thatdeclaration, mustor bewith trueor forwithout athe threadkeyword tostatic continue executionwithin an interface declaration. TheA class threadvariable pausesis execution,created via {{Object.wait()}}, {{Thread.sleep()}},when its class or someinterface otheris mechanism,prepared and is resumedinitialized later,to presumablya whendefault thevalue. requirementThe isclass truevariable andeffectively whenceases it is notifiedto exist when its class or interface is unloaded." \[[GoetzJLS 20062005|AA. Bibliography#GoetzBibliography#JLS 0605]\]. |
Anchor |
---|
| condition predicate |
---|
| condition predicate | conflicting accesses | conflicting accesses |
---|
|
Wiki Markup |
---|
*conflictingcondition accessespredicate* : TwoA accessescondition topredicate (readsis ofan orexpression writesconstructed to)from the state samevariables of variablea providedclass that atmust leastbe onetrue of the accesses is for a write. \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
Anchor |
---|
data race | data race | Wiki Markup |
---|
*data race* : Conflicting accesses of the same variable that are not ordered by a happens-before relationship" \[[JLS 2005|AA. Bibliography#JLS 05thread to continue execution. The thread pauses execution, via {{Object.wait()}}, {{Thread.sleep()}}, or some other mechanism, and is resumed later, presumably when the requirement is true and when it is notified \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
Anchor |
---|
| deadlock conflicting accesses | deadlock |
---|
|
deadlock : Two or more threads are said to have deadlocked when both block waiting for each others' locks. Neither thread can make any progress.
Wiki Markup |
---|
*conflicting accesses |
Anchor |
---|
happens-before order | happens-before order | Wiki Markup |
---|
*happens-before order* : "Two actionsaccesses canto be(reads orderedof byor writes to) the same variable provided that at least one of the accesses is a write. \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
Wiki Markup |
---|
*data race* : Conflicting accesses of the same variable that are not ordered by a happens-before relationship" \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
deadlock : Two or more threads are said to have deadlocked when both block waiting for each others' locks. Neither thread can make any progress.
Anchor |
---|
| happens-before order |
---|
| happens-before order |
---|
|
Wiki Markup |
---|
*happens-before order* : "Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the seconda happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second. \[...\] It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal. \[...\] It should Morebe specifically,noted ifthat twothe actionspresence shareof a happens-before relationship, they do between two actions does not necessarily haveimply tothat appearthey have to havetake happenedplace in that order in toan anyimplementation. codeIf withthe whichreordering theyproduces doresults notconsistent sharewith a happens-before relationship. Writes in one thread that are in a data race with reads in another thread may, for example, appear to occur out oflegal execution, it is not illegal. \[...\] More specifically, if two actions share a happens-before relationship, they do not necessarily have to appear to have happened in that order to thoseany reads." \[[JLS 2005|AA. Bibliography#JLS 05]\]. code with which they do not share a happens-before relationship. Writes in one thread that are in a data race with reads in another thread may, for example, appear to occur out of order to those reads." \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
Wiki Markup |
---|
*heap memory* : "Memory that can be |
Anchor |
---|
heap memory | heap memory | Wiki Markup |
---|
*heap memory* : "Memory that can be shared between threads is called shared memory or heap memory. All instance fields, static fields and array elements are stored in heap memory.\[...\] Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads andis arecalled unaffectedshared bymemory theor heap memory model." \[[JLS 2005|AA. Bibliography#JLS 05]\]. . All instance fields, static fields and array elements are stored in heap memory.\[...\] Local variables (§14.4), formal method parameters (§8.4.1) or exception handler parameters are never shared between threads and are unaffected by the memory model." \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
immutable : When applied to an object, this means that its state cannot be changed after being initialized. "An object is immutable if:
- Its state cannot be modified after construction;
Wiki Markup |
---|
All its fields are final;\[12\] and |
- It is properly constructed (the
this
reference does not escape during construction). - It is properly constructed (the
this
reference does not escape during construction).
Wiki Markup |
---|
\[12\] It is technically possible to have an immutable object without all fields being {{final}}. {{String}} is such a class but this relies on delicate reasoning about benign data races that requires a deep understanding of the Java Memory Model. (For the curious: {{String}} lazily computes the hash code the first time {{hashCode}} is called and caches it in a nonfinal field, but this works only because that field can take on only one nondefault value that is the same every time it is computed because it is derived deterministically from immutable state." \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
Immutable objects are inherently thread-safe; they may be shared between multiple threads or published without synchronization, though it is usually required to declare the fields containing their references volatile
to ensure visibility. An immutable object may contain mutable sub-objects, provided the state of the sub-objects cannot be modified after construction of the immutable object has concluded.
Anchor |
---|
| initialization safety |
---|
| initialization safety |
---|
|
Wiki Markup |
---|
*initialization safety* : "An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields." \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
Anchor |
---|
| interruption policy |
---|
| interruption policy |
---|
|
Wiki Markup |
---|
*interruption policy:* "An interruption policy determines how a thread interprets an interruption request - what it does (if anything) when one is detected, what units of work are considered atomic with respect to interruption, and how quickly it reacts to interruption\[12\] It is technically possible to have an immutable object without all fields being {{final}}. {{String}} is such a class but this relies on delicate reasoning about benign data races that requires a deep understanding of the Java Memory Model. (For the curious: {{String}} lazily computes the hash code the first time {{hashCode}} is called and caches it in a nonfinal field, but this works only because that field can take on only one nondefault value that is the same every time it is computed because it is derived deterministically from immutable state." \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
Immutable objects are inherently thread-safe; they may be shared between multiple threads or published without synchronization, though it is usually required to declare the fields containing their references volatile
to ensure visibility. An immutable object may contain mutable sub-objects, provided the state of the sub-objects cannot be modified after construction of the immutable object has concluded Anchor |
---|
| instance variable |
---|
| instance variable | initialization safety | initialization safety |
---|
|
Wiki Markup |
---|
*initializationinstance safetyvariable* : "An objectinstance variable is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields." \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
Anchor |
---|
interruption policy | interruption policy | Wiki Markup |
---|
*interruption policy:* "An interruption policy determines how a thread interprets an interruption request - what it does (if anything) when one is detected, what units of work are considered atomic with respect to interruption, and how quickly it reacts to interruption." \[[Goetz 2006|AA. Bibliography#Goetz 06]\]. |
Anchor |
---|
instance variable | instance variable | instance variable : An instance variable is a non-static field that is a part of every instance of the class a field declared within a class declaration without using the keyword {{static}}. If a class {{T}} has a field a that is an instance variable, then a new instance variable a is created and initialized to a default value as part of each newly created object of class {{T}} or of any class that is a subclass of {{T}}. The instance variable effectively ceases to exist when the object of which it is a field is no longer referenced, after any necessary finalization of the object has been completed." \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
liveness : Every operation or method invocation executes to completion without interruptions, even if it goes against safety.
...