Java concurrency - Revision history

Frap: /* Starting a Thread */

2025-04-30T12:17:34Z

Starting a Thread

← Previous revision		Revision as of 12:17, 30 April 2025
Line 18:		Line 18:
	=====Provide a runnable object=====		=====Provide a runnable object=====
	<syntaxhighlight lang="java">		<syntaxhighlight lang="java">
	public class HelloRunnable implements Runnable {		public class HelloRunnable implements Runnable {
	@Override		@Override
	public void run() {		public void run() {
Line 26:		Line 26:
	(new Thread(new HelloRunnable())).start();		(new Thread(new HelloRunnable())).start();
	}		}
	}		}
	</syntaxhighlight>		</syntaxhighlight>

	=====Subclass thread=====		=====Subclass thread=====
	<syntaxhighlight lang="java">		<syntaxhighlight lang="java">
	public class HelloThread extends Thread {		public class HelloThread extends Thread {
	@Override		@Override
	public void run() {		public void run() {
Line 39:		Line 39:
	(new HelloThread()).start();		(new HelloThread()).start();
	}		}
	}		}
	</syntaxhighlight>		</syntaxhighlight>

Rebecana: /* References */

2025-04-28T18:40:02Z

References

← Previous revision		Revision as of 18:40, 28 April 2025
Line 124:		Line 124:
	{{Reflist\|30em}}		{{Reflist\|30em}}

	==~~References~~==		==Bibliography==
	*{{cite book \| title= "Effective Java: Programming Language Guide" \|last=Bloch\| first=Joshua\| publisher=Addison-Wesley \| edition=third \| isbn=978-0134685991\| year=2018}}		*{{cite book \| title= "Effective Java: Programming Language Guide" \|last=Bloch\| first=Joshua\| publisher=Addison-Wesley \| edition=third \| isbn=978-0134685991\| year=2018}}
	*{{cite book		*{{cite book

74.71.99.129: agreement

2025-02-15T14:41:52Z

agreement

← Previous revision		Revision as of 14:41, 15 February 2025
Line 1:		Line 1:
	{{Short description\|Simultaneous processing in the Java language}}		{{Short description\|Simultaneous processing in the Java language}}
	{{more footnotes\|date=April 2010}}		{{more footnotes\|date=April 2010}}
	The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) is designed to support [[concurrent programming]]. All execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and prevents threads from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.		The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) are designed to support [[concurrent programming]]. All execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and prevents threads from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.

	== Processes and threads ==		== Processes and threads ==

Loverthehater: /* Thread objects */ added link to "time-slicing"

2025-01-28T02:12:58Z

Thread objects: added link to "time-slicing"

← Previous revision		Revision as of 02:12, 28 January 2025
Line 9:		Line 9:
	Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}		Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}

	Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.		Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use [[Preemption_(computing)#Time_slice\|time-slicing]] on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.

	Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}		Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}

152.42.37.90: /* Thread objects */

2024-04-13T03:16:50Z

Thread objects

← Previous revision		Revision as of 03:16, 13 April 2024
Line 9:		Line 9:
	Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}		Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}

	Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can so this differently.		Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.

	Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}		Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}

Citation bot: Add: date, authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Abductive | Category:Articles lacking in-text citations from April 2010 | #UCB_Category 241/351

2024-02-17T07:40:11Z

Add: date, authors 1-1. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Abductive | Category:Articles lacking in-text citations from April 2010 | #UCB_Category 241/351

← Previous revision		Revision as of 07:40, 17 February 2024
Line 50:		Line 50:

	====Exceptions====		====Exceptions====
	Uncaught exceptions thrown by code will terminate the thread. The main thread prints exceptions to the console, but user-created threads need a handler registered to do so.<ref>{{cite web\|last=Oracle\|title=Interface Thread.UncaughtExceptionHandler\|url=http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html\|accessdate=10 May 2014}}</ref><ref>{{cite web\|title=Silent Thread death from unhandled exceptions\|url=http://literatejava.com/threading/silent-thread-death-unhandled-exceptions/\|work=literatejava.com\|accessdate=10 May 2014}}</ref>		Uncaught exceptions thrown by code will terminate the thread. The main thread prints exceptions to the console, but user-created threads need a handler registered to do so.<ref>{{cite web\|last=Oracle\|title=Interface Thread.UncaughtExceptionHandler\|url=http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html\|accessdate=10 May 2014}}</ref><ref>{{cite web\|title=Silent Thread death from unhandled exceptions\|url=http://literatejava.com/threading/silent-thread-death-unhandled-exceptions/\|work=literatejava.com\|date=10 May 2014 \|accessdate=10 May 2014}}</ref>

	== Memory model ==		== Memory model ==
Line 127:		Line 127:
	*{{cite book \| title= "Effective Java: Programming Language Guide" \|last=Bloch\| first=Joshua\| publisher=Addison-Wesley \| edition=third \| isbn=978-0134685991\| year=2018}}		*{{cite book \| title= "Effective Java: Programming Language Guide" \|last=Bloch\| first=Joshua\| publisher=Addison-Wesley \| edition=third \| isbn=978-0134685991\| year=2018}}
	*{{cite book		*{{cite book
	\| ~~last~~ = Goetz		\| last1 = Goetz
	\| ~~first~~ = Brian		\| first1 = Brian
	\| last2 = Peierls		\| last2 = Peierls
	\| first2 = Tim		\| first2 = Tim

WikiCleanerBot: v2.05b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation)

2023-06-19T07:16:56Z

v2.05b - Bot T20 CW#61 - Fix errors for CW project (Reference before punctuation)

← Previous revision		Revision as of 07:16, 19 June 2023
Line 54:		Line 54:
	== Memory model ==		== Memory model ==

	The [[Java memory model]] describes how threads in the Java programming language interact through memory. On modern platforms, code is frequently not executed in the order it was written. It is reordered by the [[compiler]], the [[Central processing unit\|processor]] and the [[Memory hierarchy\|memory subsystem]] to achieve maximum performance. The Java programming language does not guarantee [[linearizability]], or even [[sequential consistency]]{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§16.1.1 Platform memory models\|pp=338-339}}, when reading or writing fields of shared objects, and this is to allow for [[compiler optimization]]s (such as [[register allocation]], [[common subexpression elimination]], and [[Partial redundancy elimination\|redundant read elimination]]) all of which work by reordering memory reads—writes.<ref>Herlihy, Maurice, and Nir Shavit. "The art of multiprocessor programming." PODC. Vol. 6. 2006.</ref>		The [[Java memory model]] describes how threads in the Java programming language interact through memory. On modern platforms, code is frequently not executed in the order it was written. It is reordered by the [[compiler]], the [[Central processing unit\|processor]] and the [[Memory hierarchy\|memory subsystem]] to achieve maximum performance. The Java programming language does not guarantee [[linearizability]], or even [[sequential consistency]],{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§16.1.1 Platform memory models\|pp=338-339}} when reading or writing fields of shared objects, and this is to allow for [[compiler optimization]]s (such as [[register allocation]], [[common subexpression elimination]], and [[Partial redundancy elimination\|redundant read elimination]]) all of which work by reordering memory reads—writes.<ref>Herlihy, Maurice, and Nir Shavit. "The art of multiprocessor programming." PODC. Vol. 6. 2006.</ref>

	===Synchronization===		===Synchronization===
Line 73:		Line 73:
	==== Locks and synchronized blocks ====		==== Locks and synchronized blocks ====

	A thread can achieve mutual exclusion either by entering a synchronized block or method, which acquires an implicit lock{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2.3.1 Intrinsic locks\|pp=25-26}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}}, or by acquiring an explicit lock (such as the <code>ReentrantLock</code> from the {{Javadoc:SE\|package=java.util.concurrent.locks\|java/util/concurrent/locks}} package {{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§13 Explicit Locks\|pp=277-278}}). Both approaches have the same implications for memory behavior. If all accesses to a particular field are protected by the same lock, then reads—writes to that field are [[Linearizability\|linearizable]] (atomic).		A thread can achieve mutual exclusion either by entering a synchronized block or method, which acquires an implicit lock,{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2.3.1 Intrinsic locks\|pp=25-26}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} or by acquiring an explicit lock (such as the <code>ReentrantLock</code> from the {{Javadoc:SE\|package=java.util.concurrent.locks\|java/util/concurrent/locks}} package {{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§13 Explicit Locks\|pp=277-278}}). Both approaches have the same implications for memory behavior. If all accesses to a particular field are protected by the same lock, then reads—writes to that field are [[Linearizability\|linearizable]] (atomic).

	==== Volatile fields ====		==== Volatile fields ====

Cngzz1: Clarify

2023-06-09T14:08:23Z

Clarify

← Previous revision		Revision as of 14:08, 9 June 2023
Line 13:		Line 13:
	Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}		Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}

	====Starting a ~~thread~~====		====Starting a Thread====
	Two ways to start a ~~thread~~:		Two ways to start a Thread:

	=====Provide a runnable object=====		=====Provide a runnable object=====

Cngzz1: clarify

2023-06-09T14:04:53Z

clarify

← Previous revision		Revision as of 14:04, 9 June 2023
Line 1:		Line 1:
	{{Short description\|Simultaneous processing in the Java language}}		{{Short description\|Simultaneous processing in the Java language}}
	{{more footnotes\|date=April 2010}}		{{more footnotes\|date=April 2010}}
	The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) is designed to support [[concurrent programming]]. All execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and ~~that~~ threads ~~are prevented~~ from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.		The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) is designed to support [[concurrent programming]]. All execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and prevents threads from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.

	== Processes and threads ==		== Processes and threads ==

Cngzz1: clarify.

2023-06-09T14:03:19Z

clarify.

← Previous revision		Revision as of 14:03, 9 June 2023
Line 1:		Line 1:
	{{Short description\|Simultaneous processing in the Java language}}		{{Short description\|Simultaneous processing in the Java language}}
	{{more footnotes\|date=April 2010}}		{{more footnotes\|date=April 2010}}
	The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) ~~have been~~ designed to support [[concurrent programming]], ~~and~~ ~~all~~ execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads; ~~each~~ thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and that threads are prevented from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.		The [[Java (programming language)\|Java programming language]] and the [[Java virtual machine]] (JVM) is designed to support [[concurrent programming]]. All execution takes place in the context of [[Thread (computer science)\|threads]]. Objects and resources can be accessed by many separate threads. Each thread has its own path of execution, but can potentially access any object in the program. The programmer must ensure read and write access to objects is properly coordinated (or "[[Synchronization (computer science)\|synchronized]]") between threads.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§2 Thread Safety\|pp=15-17}}{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Thread synchronization ensures that objects are modified by only one thread at a time and that threads are prevented from accessing partially updated objects during modification by another thread.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} The Java language has built-in constructs to support this coordination.

	== Processes and threads ==		== Processes and threads ==

← Previous revision		Revision as of 02:12, 28 January 2025
Line 9:		Line 9:
	Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}		Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}

	Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.		Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use [[Preemption_(computing)#Time_slice\|time-slicing]] on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.

	Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}		Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}

← Previous revision		Revision as of 03:16, 13 April 2024
Line 9:		Line 9:
	Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}		Threads share the process' resources, including memory and open files. This makes for efficient, but potentially problematic, communication.{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 78: Synchronize access to shared mutable data\|pp=126-129}} Every application has at least one thread called the main thread. The main thread has the ability to create additional threads as '''{{Javadoc:SE\|name=Runnable\|package=java.lang\|java/lang\|Runnable}}''' or '''{{Javadoc:SE\|name=Callable\|package=java.util.concurrent\|java/util/concurrent\|Callable}}''' objects. The <code>Callable</code> interface is similar to <code>Runnable</code> in that both are designed for classes whose instances are potentially executed by another thread.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§6.3.2 Result-bearing tasks: Callable and Future\|pp=125-126}} A <code>Runnable</code>, however, does not return a result and cannot throw a checked exception.{{sfn\|Goetz\|Peierls\|Bloch\|Bowbeer\|2006\|loc=§5.5.2 FutureTask\|pp=95-98}}

	Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can so this differently.		Each thread can be scheduled{{sfn\|Bloch\|2018\|loc=Chapter §11 Item 84 Don't depend on the thread scheduler\|pp=336-337}} on a different [[Multi-core processor\|CPU core]]{{sfn\|Bloch\|2018\|loc=Chapter §11 Concurrency\|p=311}} or use time-slicing on a single hardware processor, or time-slicing on many hardware processors. There is no general solution to how Java threads are mapped to native OS threads. Every JVM implementation can do this differently.

	Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}		Each thread is associated with an instance of the class <code>Thread</code>. Threads can be managed either by directly using the <code>Thread</code> objects, or indirectly by using abstract mechanisms such as <code>Executor</code>s or <code>Task</code>s.{{sfn\|Bloch\|2018\|loc=Chapter §5 Item 80: Prefer executors, tasks, and streams to threads\|pp=323-324}}