Share a little trick when I read the source code.

Hello, I am crooked.

In my previous articles, didn't I often ask you to pull the source code and then look at the code submission record?

That is to see an interface similar to this:

For example, in the above interface, you can see the file RedissonBaseLock.java, who made the change and when, and what the commit information corresponding to the change is.

In this way, it is very intuitive to see the evolution of the file.

So here comes the question. Several students have asked me this question: How can I view the git commit record in idea? Where is this interface hidden? Why isn't it in my idea?

OK, I was negligent. I preconceived that everyone should know how this came about.

But it is true that some students are not very clear, then I will share with you a little trick of reading the source code through this thing, I hope it can help you.

How to get it out?

So how to get this view out?

First, you must have a git.exe locally.

I don't need to tell you how this thing came about. If you don't even have this, it means that you have not been in contact with git before, which is another matter and is not within the scope of this article. Hurry up and install a git, and then learn how to use git.

My personal habit is to use gitbash first, which is this thing, and clone a project from github:

For example, I will use the Redssion I wrote earlier as a demonstration. You can also find an open source project that you are interested in.

Execute the following command to download the project:

git clone https://github.com/redisson/redisson.git

After the download is complete, open your idea and import the project we just downloaded.

Then open a file at random, right-click to see if there is an option for Git:

If all goes well, after you click ShowHistory, you can see this window:

If it doesn't go well, there is a problem with your git configuration.

Make the corresponding settings in the Settings of the idea:

After the setting is completed, you can click the test button next to it. If there is a pop-up window telling you the corresponding version number, it means that the configuration is successful:

In short, as long as the Version Control tab can be called up or called git in some higher versions, it means the configuration is successful.

What do you think?

Whether at work or when writing articles, I usually just look at the submission records in the idea, and I will not use the git in the idea to submit the code.

In fact, the visual page of pulling code and submitting code in idea is very good, but I still prefer to type commands directly in gitbash. There is no special reason, but it seems to be very high.

So, how do you see it?

Take for example the Redisson article I wrote earlier.

It is mainly written around the RedissonLock.java class. How do I know this class?

In fact, if you debug yourself with the problem, you can definitely locate this class, but it takes a little time.

I used to start writing case debugs crazily after setting up the environment.

Now that I'm smarter, after the environment is settled, I'll go to github's issues and search for keywords.

For example, my keyword is deadlock:

But I strongly suggest you don't search in Chinese, use English, deadLock:

There is a lot of information that can be found in this way. The rest is that you click one by one to see if it is the same or similar to the problem you have encountered.

This process will take a little time, but it is definitely faster than diving into the source code to find the answer.

For example, in the screenshot above, the last issue called Deadlock after Redis timeout is what I'm looking for:

The reproduced code, the versions involved, and the expected results and actual performance are given here.

For example, after I found this link, for me, I found a test case, and he told me a command:

CLIENT PAUSE 5000

Before this, I didn't know this command. I have been thinking, how should I simulate the phenomenon that Redis executes the command timeout when I reproduce the demo?

Some of the solutions I could think of at the time were bigkey, or pouring a lot of data into it, and then I executed the keys * command, or a save command, to simulate Redis blocking.

However, this is all workload and the blocking time is uncontrollable. And this command directly solved my problem, at least let me take a few detours.

Similarly, this issue is also associated with several other issues, which are officially considered to be caused by the same cause:

Then how to solve it?

In general, they should be associated with a pr, through which I can directly associate the corresponding repair content.

But this time they did a tricky operation, and directly made a SNAPSHOT version first, and did not associate pr:

what to do?

At this time, I want to see how he fixes this problem, what should I do?

The git plugin in the aforementioned idea comes in handy.

First of all, I know from his comment time that it is March 13, 2019, so I can directly locate the content submitted on that day in the tool.

Click the Log tab in the Version Control view, you can see all the commits in the entire project history, it will sort you in chronological order, and it is easy to find the relevant commits of the day:

If you find it hard to find, you can also filter directly by date:

Judging from the commit information submitted that day, I knew I was in the right place.

And here I just modified the RedissonLock.java class, so I found this key class:

Then click in and analyze the specific modification of this class, which is the place I should focus on when I find the debug.

Another example is the bug that the watchdog fails:

https://github.com/redisson/redisson/issues/3714

In this, a pr is directly associated, and then we can find the submitted code through this link, as well as its corresponding issues.

This thing is a two-way go.

And I can also know that the class corresponding to this submission is called RedissonBaseLock.java:

Then I can go back to the idea view and directly look at the submission record of this class:

At first glance, I found that this buddy submitted a total of three times. And also found out that this class is quite young, with its first submission on January 21, 2021.

I previously stepped on an unusual bug about distributed locks in "Step on! " This article leaves a question for thinking:

It is caused by these three commits.

Let me show you what the three commits are.

First submitted for the first time, the else branch was added, the cancelExpirationRenewal method was executed once, and the input parameter was threadId.

Contains is to reduce the number of reentries of the current thread by one.

But there is a major premise for going to the else branch is that the lua script that renews the lock returns false, which means that the lock is gone.

The locks are gone, so what are you doing to maintain the number of reentries?

Just remove this object directly from the MAP.

How to take it off?

Just pass in null:

Therefore, there is a second submission, changing the input parameter from threadId to null:

So what is the third submission for?

Can't see what it's doing?

Don't worry, I will give you a screenshot like this and you will understand:

It used to be the tab tab, which was later changed to four spaces. It's a matter of coding style.

When it comes to using tabs or spaces, this is another topic that has been debated in the field of programming.

I remember that I watched an American TV series called "Silicon Valley" before. The protagonist in it had a fight with his girlfriend over whether to use tab or space.

Then...

I also remembered a boring question while writing the article and went to find the answer.

I want to know when Redisson introduced the watchdog mechanism, I want to see what this dog looks like at the beginning.

How did I find it?

First of all I know that the code to start the watchdog is the method renewExpiration located in RedissonLock.java:

Then I use the renewExpiration method in the historical submission record of RedissonLock.java to find out when the method was first submitted.

So I quickly found this time on March 13, 2019:

I just found out that the original watchdog has changed its name. It was called scheduleExpirationRenewal before, and then it was renamed renewExpiration.

Obviously, I think the new name is better.

Then I continued to find when scheduleExpirationRenewal first appeared. I searched and searched, and found this commit on December 14, 2015:

Good guy, this dog has a former name called newRefreshTask.

Finally, I found the place where newRefreshTask first appeared, which is on July 4, 2015:

This is the birthday of the watchdog, less than two months from today, I wish it a happy birthday in advance.

However, I have to rant.

There are a lot of things submitted for this commit on watchdog. You can right-click on this commit and click on the options boxed below:

You can see everything in this commit:

Thirty-one files were submitted that included the watchdog mechanism.

However, the submitted commit information is very rudimentary, and it only reflects the use of this feature of the LUA script because it involves transaction operations.

This is an example of a very bad commit.

But then you think about it, how do you write the example every time you submit it, and are you often lazy.

Don't ask how I know.

Therefore, the commit information submitted every time should be written carefully, because you must know that there are always boring people like me who will go through some useless knowledge and point it out.

For example, if I ask you, is there any use for me to find this description of the watchdog mechanism besides letting you know its birthday and several past names?

Yes, not at all.

Congratulations, you have learned another useful knowledge point.

another one

I'll show you one more project, Dubbo.

Or as I said earlier, pull the project down, and then click the log here, you can see all the commits in the entire project history:

Scroll to the bottom to find the first commit in history:

The first submission was submitted by Fei Liang on October 20, 2011 at 23:04.

But from the committed commit information, we also know that this is an empty commit.

The real first commit is 2 minutes later at 23:06:

9 modules, a total of 669 files, is the prototype of Apache's top-level open source project in the future, which has been bumpy, almost dead, and friends and businessmen.

On October 20, 11 years ago, Liang Fei worked from 23:00 in the evening to 5:25 in the morning, and finally tagged Dubbo with the first milestone: 2.0.7.

During this period, a Weibo was also released:

And he himself, at noon the next day, also announced this on his blog:

https://www.iteye.com/blog/javatar-1206888

Why did Dubbo choose to open source on this day?

I think it should be to catch up with the Qcon global software developer conference two days later:

That day was the beginning of Dubbo's true sense of standing in the public eye and accepting praise and ridicule.

In the idea's view, you can also filter the records submitted by the specified person.

For example, Liang Fei used the following accounts to submit codes:

I filtered and found that there are as many as 1294 times, the last commit was on April 1, 2015:

And I also found that he is very liver, and there are several submission records at such a time point:

Then I also looked for a few classes to see how much of his code remained in those classes after more than 10 years of development.

First, let me show you the class AbstractLoadBalance.java related to this load balancing strategy.

Right-click on this class and select git->Annotate to bring up the left (time-user) view:

This represents the current class, who submitted each line of code and when.

Liang Fei can still be seen.

And I show you this:

This method is to warm up the new machine when Dubbo starts, and give weights a little bit. The first minute gives 10% flow, the second minute 20% flow... At the tenth minute, the machine has basically been fully warmed up, so it can give 100% flow.

As for why it is necessary to warm up, this is related to the JVM. If you are interested, you can study it.

It is this function, this core method, after more than 10 years, except for a little fine-tuning, its core algorithm and core logic have not changed at all.

For another example, let me show you the implementation of the least active load balancing strategy LeastActiveLoadBalance.java:

Since the initial submission, it has not been modified several times in total.

But you need to know that each commit has its meaning, such as these two times:

One submission is to change the variable leastIndexs to leastIndexes, because index ends with x, and nouns ending with s, x, sh, ch, its plural form should be added es. This is a little knowledge of English.

One submission is to replace Random with ThreadLocalRandom, because the latter has better performance. This is a little programming knowledge, and the reason behind it is worth digging into. Depends on whether there is a heart.

You can also compare the initial version and the latest version, the core algorithm and core logic have basically not changed:

What do these two classes tell me?

Compared with the addition, deletion, modification and inspection of business code, only algorithms and stable algorithms are more likely to remain in the long river of time, and they will last for a long time.

Then, go back to the log tab, you will find a very strange phenomenon.

Throughout 2014 and 2015, no code has been committed a few times:

In fact, from 2013 to 2017, there were basically not many submissions.

Why is this?

This has to say about Dubbo's rough life.

As mentioned earlier, in 2011, it belonged to a wealthy family and came out of Alibaba Open Source.

But on October 23, 2012, after Dubbo 2.5.3 was released, Ali basically stopped the maintenance and upgrade of Dubbo.

Then until September 7, 2017, Dubbo quietly released version 2.5.4 on GitHub. Subsequently, 2.5.5, 2.5.6, 2.5.7 and other versions were quickly released. At the Yunqi Conference held in October, Ali announced that Dubbo was included in the group's key maintenance open source projects, which means that Dubbo came back to life and began to re-enter the fast lane.

In the five years from 2012 to 2017, Dangdang started a branch of Dubbox by itself, which is equivalent to helping Dubbo continue his life.

On January 8, 2018, Dubbo version 2.6.0 was released. The new version merges the previous open source Dubbox of Dangdang, realizing the unified integration of Dubbo versions.

Then in February 2018, Alibaba announced that it would donate Dubbo to apache and enter the apache incubator.

On May 21, 2019, after a long incubation period, Dubbo ushered in graduation. Become a top-level project of the Apache Foundation.

You should know the story after that. Dubbo has now got 3.0 and is ready to work on the cloud native track.

So you see, this is a cool routine.

This is the story of a wealthy child who accidentally wandered the streets, was adopted, took good care of him, and finally returned to the top with exclamations.

So what does this story tell us?

It tells us that it's really nice to have a good dad. If Dubbo was not open sourced by Alibaba, it would be very difficult to come back to life, and half of it would have disappeared in the long river of history.

Having said that, the things mentioned above can all be derived from the view of the idea I mentioned to you in this article.

And I just introduced you some very common usage, you can dig out your own concerns that are more suitable for you.

This thing, I usually have nothing to do, pull down a project that interests you, look at the submission record, and see the new features.

As I said earlier, every submission has its meaning, and some submissions are worth digging deeper, depending on whether there are people with intentions.

You say, isn't this thing better than the novel?

Welcome to the public account why technology, and receive the latest articles as soon as possible.