Thread of java source code analysis (1)

    Another week has passed, let me explain what happened recently:

        There are only two classes this week, and Wednesday is equivalent to no class. We have two days off on Thursdays, Fridays and weekends because the school has sports meetings. In terms of time arrangement, Wednesday is equivalent to a waste, the state is not good, and the time is too fragmented. Go slowly Thursday and Friday. But on Friday afternoon and evening, the state was not very good, something went wrong in my mood, and I was a little negative. This led to: studying for half a day on Saturday, entertaining for half a day, and binge-watching movies at night. Overall, not very satisfied, but barely acceptable.

        From the historical problems of last week, I found that I had made too much of the basics, but it caused my example practice to lag behind, and I also encountered various reasons for neglecting myself in the middle. Therefore, I have been reflecting for a long time this week, and I have also blamed myself for a long time. Fortunately, although I slack off subjectively and emotionally, I haven't wasted this vacation too much according to the original study habits. 

    Then there is the summary of learning:

        As planned, the Thread source code reviewed this week. Old rules, first picture:


    This picture is less than all the systems I have seen before. The problem is that on the one hand, this involves more interaction with the VM, so many implementations are either directly called by the JVM or handed over to C for processing. So not too many tricks. On the other hand, although the source code is less, it is not easy to understand. It may be that I have been looking at the source code for a long time in the past half month, which has led to a little tired and my mind is not flexible enough. Come in and continue to explain according to the timeline of viewing the source code yourself:

    Thread, we often see him mostly in multi-threaded programming. In fact, from the perspective of the operating system, we know that an application, whether it is a human-computer interaction interface with ui, or a black background with white characters cmd command line, or a placeholder hidden in the task manager, it is a process. In the introductory computer class, we should have also heard that a process consists of threads. I think this should be our first exposure to threads, not the first exposure when learning multithreaded programming. Can't remember in which book I read it, processes are one of the most successfully applied techniques in computer science. The mutual switching between processes constitutes the content of the colorful computer systems we see. I found myself beside the point again, and bluntly pulled back a wave. Well, cough, cough~~, today is the thread, Thread, take a look at its source code:

    

     The above picture shows its reference relationship: I roughly understand that it needs to use the basic package: the reference in the ref package, the thread safety related tool class in the concurrent package, and the reflection class in the sun package. (Note that it is not a reflect package) Well, I understand.

    Let's take a look at the official authoritative explanation:


    The above figure illustrates some basic properties of a thread. After it is created, the weight defaults to the same as its parent class. Threads are divided into daemon threads and non-daemon threads. When all daemon threads are finished running, the program stops, that is, the thread is finished. A thread created by a daemon thread is also a daemon thread. Usually the main thread we see is called the main thread, and the program runs the content in it, so it is naturally a non-daemon thread. It should be noted that it is a little special from ordinary threads, but it is not fundamentally different, which will be covered later. continue:





    The above three pictures show its attribute distribution. You can see that it has several main dependencies, such as class loader, thread group, Runnable interface, flag bit of daemon thread, weight, thread Id, and thread state. It should be noted that: There is a stackSize, which I believe we all compare attributes, and the Chinese meaning is also easy to get, that is, the stack size. At the same time, notice that there are several properties in it that are directly maintained by the VM. In addition, there is a ThreadLocal class that records some information about the local (relative to the VM). You can go in and see:



    By browsing the class introduction, you can roughly know that it saves a local copy for no thread, and when the thread ends, it is processed by the garbage collection mechanism. Package private, maintain map with weak reference to key, hash adaptive, maintain thread-local value. It's been a while since I watched it, and the more I look at it, the more confused it gets haha. Go back:


    Several constant values ​​are recorded in the above figure, all of which are related to thread weights. That is, the default weight, the minimum weight, and the maximum weight. Another important method is the currentThread() declared as native. It can be known that the judgment of the current thread in java is not handled by itself, but to the jvm to judge the current thread. It can be used in many ways. continue:


    Thread scheduling. Following the general translation of Youdao, I think it is more important to prevent excessive CPU usage. At the same time, note that it is a native method. 


    This is the most important method in the thread. Because the purpose of the thread we use is also there. It can be seen that this method filters the main thread and threads in the system thread group when judging the thread status. This is why the main thread mentioned above is a bit special. It is said that the main thread can also not be called main, but it seems that we need to modify the bootstrap program. Also give the second half of its method:


    It can be seen that the actual method of thread startup is start0(), which is a native method. Note that the start() method does a lot of state maintenance, state updates, information maintenance, environment checks, etc. Here you need to pay attention to the top comment part of the start method: The method to start the execution of this thread, the jvm calls the run method of this thread. In fact, the run method is the code to be executed by the thread, which is implemented by overriding the run method of the runnable interface. There are at least two threads running at this time, one is the thread of the calling thread and the other is the thread of the called thread. A thread cannot be started at the same time as the start state. continue: 


    This is the method to exit the thread. See its official authoritative note: This method is called by the system to give the thread a chance to clean up (maintain local state) before actually exiting. It can be seen that it does these things: initializes the thread group governed by this thread to be empty, (the threads in the thread group should be stopped before that); initializes the tartet, that is, the target code block to be executed, to be empty; Initializes the thread-local record to null, and initializes some other properties. As for why initialization is required here, I think it is to reduce memory consumption. I really can't think of any other reason, please forgive Xiaobai. continue:


    The interruption of the thread, you can see that it is also native, and it is thread-safe at the same time. 


    The thread-safe method is responsible for the interaction between multiple threads. I used it in the previous practice, but I forgot the specific use. Seeing its comments seems to say: Set the timeout period of the thread. Have time to practice carefully to solve this doubt. 


    A method to set the created thread as a daemon thread. Note the official authoritative explanation section: This method must be called before the thread is executed.


    The toString method of the thread, the advantage means. I find the toString method of many classes interesting. The premise is that it has to override the Object method!


    As you can see above, there is an attribute in the Thread method that records the stack size. This method is a bit sloppy. It records the information in the stack. Where does the large string of fights that we often see come from? That's it! ! Look, StactTrace, stack frame information. Hey-hey. It is understood that each thread has its own stack frame information, and all stack frame information is stored in a two-dimensional array of StackTraceElement. The first dimension of the two-dimensional array records the thread, and the second dimension records the stack frame information of the current thread. 

    Also a version with easy instructions:


    Looking at the progress bar, I found that there is a lot of content, so let's open a new one. 

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327032696&siteId=291194637