One, thread group
This is some of the constructor methods of the thread class, and you can see that there is one argument for the Threadgroup class, which is the thread group.
This is described in the JDK:
A thread group represents a collection of threads. In addition, thread groups can contain other thread groups. The thread group forms a tree,
In the tree, each thread group has a parent thread group, in addition to the initial thread group. Allow threads to access information about their own
The information for the thread group, but does not allow it to access information about its thread group's parent thread group or any other thread group.
With the Threadgroup object, you can manipulate all the thread objects in a thread group, simplifying the thread group
The management of multiple threads.
Although the thread group looks very useful, we cannot use it for the following reasons:
But these methods have been discarded, they can easily induce deadlocks and other problems.
But we should know something about Threadgroup's contribution to the exception that Cui produced during thread execution.
public class Test {public static void main (string[] args) {Runnable r = new Runnable () {@Overridepublic void run () {int a = 1/0;}}; Thread th = new Thread (r); Th.start ();}}
Operation Result:
Exception in Thread "Thread-0" Java.lang.ArithmeticException:/By Zeroat Test$1.run (test.java:10) at Java.lang.Thread.run (thread.java:745)
Above is the result of processing when an exception is thrown within the run () method of the thread. So here's the problem, the exception in the thread
How it is handled, the process is this, and when an exception is thrown in the run () method, the JVM gets a Thread.uncaughtexceptionhandler
instance that has the thread'ssetUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)方法
设置,当找到这个Handler时,线程执行他的void uncughtException();进行异常处理打印抛出异常。
那么Thread.UncaughtExceptionHandler又是从哪里来的呢?
如上他是被Thread类所封闭的一个接口,所谓封闭类相当于如下:
public class Test {public interface myinterface{}}
But we don't seem to be doing Setuncaughtexceptionhandler(thread.uncaughtexceptionhandler eh) This step
So how is this exception handled? In fact, when we do not set exception handler, he will automatically start the default
Exception handling process, the source code is as follows:
public static void setdefaultuncaughtexceptionhandler ( Uncaughtexceptionhandler eh) { SecurityManager Sm = system.getsecuritymanager (); if (sm != null) { sm.checkpermission ( new Runtimepermission ("Setdefaultuncaughtexceptionhandler") ); } defaultUncaughtExceptionHandler = eh; }
The method is to set the default processing mode, that is, just the way the program was printed. Let's set up our own exception handling:
Import Java.lang.thread.uncaughtexceptionhandler;public class Test {public static void main (string[] args) {Runnable R = N EW Runnable () {@Overridepublic void run () {int a = 1/0;}}; Thread.uncaughtexceptionhandler tu = new Thread.uncaughtexceptionhandler () {@Overridepublic void uncaughtexception ( Thread T, Throwable e) {System.out.println ("Custom exception handling ... "+ E +" The thread is "+ T";}}; Thread th = new Thread (r); Th.setuncaughtexceptionhandler (TU); Th.start ();}}
Operation Result:
Custom Exception Handling ... Java.lang.ArithmeticException:/By zero The thread is Thread[thread-0,5,main]
But for a while, it seems that abnormal handling and threadgroup have nothing to do with it, observation:
Threadgroup implements the Thread.uncaughtexceptionhandler, so
When we did not call Setuncaughtexceptionhandler(thread.uncaughtexceptionhandler eh),
The JVM will automatically find the Threadgroup object for the thread, and find his rewritten uncaughtexception (thread t,throwable e)
Method for exception handling, and if the Threadgroup object does not override this method, he will find the method of its parent class to execute.
Second, thread local variables
See previous blogs: http://blog.51cto.com/12222886/1940714
Third, the timer framework
The execution of some tasks requires that we define a time that is not immediately executed, and that some tasks may
Timing is performed only once, while others are timed repeatedly, and the timer framework solves these problems.
Java.Util.Timer and Java.Util.TimeTasks
Details are not detailed, see JDK documentation
Java threading and concurrent programming practices----additional threading capabilities