Sequential programming, that is, everything in the program can only perform one step at any time.Concurrent programming, the program can execute multiple parts of the program in parallel.
Threads can drive tasks, so you need a way to describe tasks, which can be provided by theRunnableinterface. To define a task, just implement theRunnableinterface and write therun()method so that the task can execute your commands.
When a class is derived fromRunnable, it must have arun()method, but there is nothing special about this method - it does not create any inherent threading capabilities . To implement threaded behavior, you mustexplicitly attach a task to a thread.
FixedThreadPoolandCachedThreadPool
FixedThreadPool, expensive thread allocation can be performed in advance at once, thus limiting the number of threads. This saves time because you don't have to pay the fixed overhead of creating a thread for each task. In event-driven systems, event handlers that require threads can also be served as you wish by getting the threads directly from the pool. You won't abuse the available resources because the number of Thread objects used by FixedThreadPool is bounded.
Note that in any thread pool, existing threads will be automatically reused when possible.
Although this book will useCachedThreadPool, you should also consider usingFiexedThreadPoolin code that spawns threads.CachedThreadPooltypically creates as many threads as required during program execution and then stops creating new threads when it recycles old threads, so it is a reasonableExecutorfirst choice. Only if this approach causes problems should you switch toFixedThreadPool.
SingleThreadExecutoris likeFixedThreadPoolwith the number of threads1. (It also provides an important concurrency guarantee that other threads will not (that is, no two threads will) be called. This will change the locking requirements of the task)
If submitted toSingleThreadExecutorMultiple tasks, then the tasks will be queued, each task will run to the end before the next task starts, and all tasks will use the same thread. In the example below, you can see that each task is completed in the order in which they were submitted, and before the next task starts. Therefore,SingleThreadExecutorwill serialize all tasks submitted to it and will maintain its own (hidden) queue of pending tasks.
-Runnableis an independent task that performs work, but it does not return a task value. If you want the task to return a value when completed, you can implement theCallableinterface instead of theRunnableinterface.Callableintroduced in Java SE5 is a generic with type parameters. Its type parameters represent the methodcall()(instead ofrun()) and must be called using theExecutorService.submit()method.
Another idiom you may see is the self-managedRunnable.
This is no special difference from inheriting fromThread, except that the syntax is slightly more obscure. However, implementing an interface allows you to inherit from a different class, whereas inheriting fromThreadwill not.
Note that the self-managedRunnableis called in the constructor. This example is fairly simple and therefore probably safe, but you should be aware that starting a thread in a constructor can become problematic because another task might start executing before the constructor ends, meaning that the task Ability to access objects in an unstable state. This is another reason to preferExecutorrather than explicitly creating aThread object.
Thread group holds a collection of threads. The value of thread groups can be summed up by quoting Joshua Bloch: "It's best to think of thread groups as an unsuccessful attempt, and you can just ignore it."
If you've spent a lot of time and effort trying to discover the value of thread groups (like me), then you might be surprised why there hasn't been an official statement from Sun on the subject in years. The same question has been asked countless times about other changes in Java since then. The life philosophy of Joseph Stiglitz, the Nobel laureate in economics, can be used to explain this problem. It is called The Theory of Escalating Commitment: "The cost of continuing to make mistakes will be borne by others, while the cost of admitting mistakes will be borne by yourself. Commit."
Due to the nature of threads, you cannot catch exceptions that escape from the thread. Once an exception escapes the task'srun()method, it will propagate out to the console unless you take special steps to catch this erroneous exception.
You can think of a single-threaded program as a single entity that solves the problem domain and can only do one thing at a time.
Because thecanceledflag is of typeboolean, it is atomic, that is, such as assignment Simple operations like returning values occur without the possibility of interruption, so you won't see this field in an intermediate state in the process of performing these simple operations.
It is important to note that the incrementing process itself requires multiple steps, and the task may be suspended by the pure mechanism during the incrementing process - that is, in Java, incrementing Not an atomic operation. Therefore, even a single increment is not safe without protecting the task.
and callshutdownNow()on#Executor, it will send ainterrupt()Called to all threads started by it.
#ExecutorBy callingsubmit()instead ofexcutor()# to start the task, you can hold the context of the task.submit()will return a genericFuture. The key to holding thisFutureis that you can callon it cancel(), and therefore can be used to interrupt a specific task. If you passtruetocancel(), then it will have permission to callinterrupt()on that thread to stop it. Therefore,cancel()is a way to interrupt a single thread started byExcutor.
# SleepBlock()is an interruptible blocking, whileIOBlockedand ## #SynchronizedBlockedare uninterruptible blocking. The examples of the above three classes prove that I/O and waiting onsynchronizedblocks are uninterruptible. Neither I/O nor attempts to callsynchronizedmethods require anyInterruptedExceptionhandlers.As you can see from the output of the examples for the three classes above, you can interrupt calls to
sleep()(or any call that requires anInterruptedException). However, you cannot interrupt a thread that is trying to acquire asynchronizedlock or that is trying to perform an I/O operation. This is a bit annoying, especially when doing I/O tasks, because it means that IO has the potential to lock up your multi-threaded program. Especially for Web-based programs, this is a matter of stakes.
wait()allows you to wait for a certain condition to change, and changing this condition is beyond the scope of the current method. control ability. Often this condition will be changed by another task. You definitely don't want to keep doing an empty loop while your task is testing this condition. This is called a busy wait and is generally a bad use of cycles. Thereforewait()will suspend the task while waiting for changes in the external world, and only whennotify()ornotifyAll()occurs, That is to say, when something of interest occurs, the task will be awakened and check the changes. Therefore,wait()provides a way to synchronize activities between tasks.
sleep()is called. This is also the case when callingyield(). It is important to understand this.
wait(),notify()andnotifyAll()have a special aspect, that is, these methods are base classObject A part of, not part ofThread.
In the discussion about Java's threading mechanism, there is a confusing description:notifyAll()will wake up "all The task is waiting for you.” Does this mean that any task in thewait()state anywhere in the program will be awakened by any call tonotifyAll()? There are examples showing that this is not the case - in fact, whennotifyAll()is called for a specific lock, only tasks waiting for this lock will be awakened.
The dining philosophers problem proposed by Edsger Dijkstrar is a classic example of deadlock.
To fix the deadlock problem, you must understand that a deadlock occurs when the following four conditions are met at the same time:
CountDownLatchobject. Any method calling wait() on this object will block until the count value reaches 0. When other factors finish their work , you can call countDown() on the access object to reduce the count value.CountDownLatchis designed to be issued only once, and the count value cannot be reset. If you need a version that resets the count, you can useCyclicBarrier.
countDown()is not blocked when this call is made. Only the call toawait()# will be blocked until the count value is reached0.
#CountDownLatchis typically used to divide a program intonindependent solvable tasks and create # with valuen##CountDownLatch. When each task completes,countDown()is called on this latch. Tasks waiting for the problem to be resolved callawait()on this latch, suspending themselves until the latch count ends.21.7.2 CyclicBarrier
For example, the program horse racing program: HorseRace.java
21.7.3 DelayQueue
# ##(synchronous Queue), used to place objects that implement theDelayedinterface, in which objects can only be removed from the queue when they expire. This queue is ordered, that is, the head object is the first to expire. If there is no expired object, then the queue has no head element, sopoll()will returnnull(because of this, we cannot placenullinto this queue). As mentioned above,DelayQueuehas become a variant of the priority queue.21.7.4 PriorityBlockingQueueThis is a very basic priority queue with blocking read operations. The blocking nature of this queue provides all the necessary synchronization, so you should note that there is no need for any explicit synchronization here - you don't have to worry about whether there are elements in this queue when you read from it, because this queue When there are no elements, the reader will be blocked directly.
"Greenhouse control system" can be regarded as a concurrency problem, each desired greenhouse event is a task that runs at a scheduled time.ScheduledThreadPoolExecutorcan solve this problem. Among them, schedule() is used to run the task once, and scheduleAtFixedRate() repeatedly executes the task every specified time. Both methods receive the delayTime parameter. Runnable objects can be set to execute at some point in the future.
BlockingQueue: Synchronous queue, when the first element is empty or unavailable, wait (blocking, Blocking) when executing .take().
#SynchronousQueue: It is a blocking queue with no internal capacity, so each put() must wait for a take(), and vice versa (that is, each take() must wait for a take() Wait for a put()). It's like you're handing an object to someone - there's no table on which to place the object, so you can only work if the person reaches out and is ready to receive the object. In this case, the SynchronousQueue represents a location set in front of the diner to reinforce the concept that only one dish can be served at any time.
One very important thing to observe about this example is the management complexity of using queues to communicate between tasks. This single technique greatly simplifies the process of concurrent programming by inverting control: tasks do not interfere with each other directly, but send objects to each other via queues. The receiving task handles the object and treats it as a message rather than sending messages to it. If you follow this technique whenever possible, your chances of building a robust concurrent system are greatly increased.
Danger of “microbenchmarking”: This term usually refers to performance testing of a feature in isolation and out of context. Of course, you still have to write tests to verify assertions such as "Lock is faster than synchronized", but you need to be aware of what is actually happening during compilation and at runtime when writing these tests.
Different compilers and runtime systems will differ in this regard, so it's difficult to know exactly what will happen, but we need to prevent the compiler from predicting the possibility of the outcome.
Using Lock is usually much more efficient than using synchronized, and the overhead of synchronized seems to vary too much, while Lock is relatively consistent.
Does this mean you should never use the synchronized keyword? There are two factors to consider here:
First, the size of the method body of the mutually exclusive method.
The second is that the code generated by the synchronized keyword is more readable than the code generated by the "lock-try/finally-unlock" idiom required by Lock. a lot of.
Code is read far more often than it is written. When programming, communicating with other people is much more important than communicating with the computer, so the readability of your code is crucial. Therefore, it is of practical significance to start with the synchronized keyword and only replace it with a Lock object during performance tuning.
The general strategy for these lock-free windows is: modifications to the container can occur simultaneously with read operations, as long as the reader only You can see the results of completed modifications. Modifications are performed on a separate copy of a portion of the container data structure (sometimes a copy of the entire data structure), and this copy is not visible during the modification process. Only when the modification is completed, the modified structure is automatically exchanged with the main data structure, and then the reader can see the modification.
Optimistic locking
As long as you are primarily reading from a lock-free container, it will be much faster than its synchronized counterpart because the overhead of acquiring and releasing locks is eliminated. This is still the case if a small number of writes need to be performed into a lock-free container, but what counts as a "small amount"? This is a very interesting question.
An additional benefit of threads is that they provide lightweight execution context switches (about 100 instructions) rather than heavyweight process context switches (thousands of instructions) instruction). Because all threads within a given process share the same memory space, lightweight context switching only changes the program's execution sequence and local variables. Process switches (heavyweight context switches) must change all memory space.
related articles:
Java Programming Thoughts Learning Class (6) Chapter 19 - Enumeration Type
Java Programming Thoughts Learning Class (7) Chapter 20 - Notes
The above is the detailed content of Java Programming Thoughts Learning Class (8) Chapter 21 - Concurrency. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
