The explosive popularity of ChatGPT and the recent flurry of large-scale model developments have thrust the field of artificial intelligence into the spotlight. As a tech enthusiast keen on exploring various technologies, understanding the principles behind these advancements is a natural inclination. Starting with deep learning is a logical step in delving deeper into AI, especially since I’ve already studied Professor Andrew Ng’s Machine Learning course. Now, through his Deep Learning Specialization, I am furthering my knowledge in this domain. This article aims to demystify deep learning, drawing insights from the first course of the specialization.

In this article, we will focus on some relevant knowledge points about distributed transactions. This is an indispensable technology for learning distributed systems. The most common case is the bank transfer problem. Account A transfers 100 yuan to account B. Then the balance of account A should decrease by 100, and account B should increase by 100. The two steps must both succeed to be considered successful. If only one succeeds, it should be rolled back. If A and B are not in the same environment or system, then this transaction is a distributed transaction. So in this case, how to ensure the correct execution of the transaction and what execution plans are there?

In the last Spring source code analysis, we skipped part of the code on Spring to solve the circular dependency part of the code, in order to fill the hole, I here another article to discuss this issue.

First of all, explain what is circular dependency, in fact, very simple, is that there are two classes they are dependent on each other, as follows.

@Component
public class AService {

    @Autowired
    private BService bService;
}
@Component
public class BService {
  
    @Autowired
    private AService aService;
}

AService and BService are obviously both internally dependent on each other, singled out as if to see the common deadlock code in the multi-threaded, but obviously Spring solves this problem, otherwise we would not be able to use it properly.

The lifecycle of Spring Beans is really one of the most frequently asked questions about Spring in interviews. I have been stumped by this question more than once. I was wrong to try to rote memorize the steps. On the surface it looks like just reciting a process, but actually many interesting knowledge points are involved in this process.

The following diagram is probably something many people have seen the same or similar:

Every Java developer is no stranger to locks, which frequently come up in both work and interviews. However, for most small-scale projects, or single-machine applications, Java’s juc (java.util.concurrent) is generally sufficient. Yet as application scales grow and we move into distributed systems, relying solely on tools like synchronized and lock becomes inadequate. This article will discuss several common methods to implement distributed locks in such systems.

Database Method for Implementing Distributed Locks 

First, let’s talk about the database method, something everyone is very familiar with. Here, we use MySQL as the database. The method might vary slightly with other databases, but the general idea is the same. I will assume that everyone is familiar with the ACID of transactions and the isolation mechanism, so I won’t waste time going over these.

As a Java Developer, the word Map is definitely not unfamiliar. Whether it’s in the development process or going out for an interview, we often encounter it. The most frequently used and interview questions are nothing more than these few, HashMap, HashTable, ConcurrentHashMap. So this article will summarize these points.

Starting with HashMap

HashMap is the most frequently used of the several Maps mentioned above, after all, the scenarios that need to consider multithreading concurrency are not too many. Below is a relationship diagram of Map, you can understand it.