Java concurrent programming, Chapter Nineth graphical user Interface application interface reading notes

One, why the GUI is single-threaded traditional GUI applications are usually single-threaded.
1. There is a need to call the poll method at each location of the code to get the input event (which would be very confusing to the code)
2. Run the entire code of the application indirectly through a "main event loop".

It is assumed that the code that is called in the main event loop takes a very long time to finish running. The user interface will "freeze" until the code finishes running. This is due to the ability to handle possibly user interface events only after the run control is returned to the main event loop.

The effort to try multi-threaded GUI frames, most often due to static conditions and deadlock-induced stability problems, goes back to the old way of single-threaded time queue model.

1. Sequential Event handling
Because there is only one thread in the Process GUI task. All tasks do not need to be considered concurrent and run sequentially, but the problem is to assume that the task is running too long, or that the operation may not be responding. (Android will prompt Andorid not response exception)


2. Thread Limits in Swing
GUI single-threaded rules: components and models can only be created, altered, and requested in the event dispatch thread.
In Andorid, it is assumed that creating a child thread or updating a UI operation throws an exception.

In the short-term GUI task GUI application, the event originates from the event thread. Bubbling seems to pass to the listener provided by the application, assuming it is a simpler color change, and can be processed directly in the event thread.

Three, time-consuming GUI task due to GUI task thread limit, so it is necessary to handle the time-consuming operation of sub-threading, usually finally need to refresh in the child thread.

1. Cancellation
2. Progress and completion identification
3. SwingWorker
Using Asynctask in Andorid

Iv. the simplest way to share a data model to avoid responsiveness is to read it once in memory at initialization time, so you need to consider whether you are consuming too much memory.

1. Thread-Safe Data model
Concurrenthashmap cannot provide a consistent snapshot of the data.

Copyonwritearraylist the same time for thread safety, consistency, and good responsiveness.
2. Decomposing the data model
Suppose that a data model must be shared by multiple threads and cannot implement a thread-safe model for reasons such as congestion, consistency, or complexity. Be able to consider the use of decomposition model design.

V. Other forms of single-threaded subsystems in some cases, synchronization or deadlock problems cannot be avoided. For example: the native repository (Native library) requirements, through system.loadlibrary loading. Must be run on the same thread.

Use the future and newsinglethreadexecutor together to handle single-threaded tasks that can be canceled.

Java Concurrent Programming Combat Nineth Chapter Graphical user Interface application interface reading notes