CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài viết phỏng vấn blog CFSDN tổng hợp này: các câu hỏi liên quan đến thiết kế flash sale, AQS, đồng bộ được tác giả sưu tầm và biên soạn. Nếu các bạn quan tâm đến bài viết này thì nhớ like nhé.

1. Người phỏng vấn: Thiết kế hệ thống flash sale như thế nào? Bạn có thể vui lòng giải thích quá trình này?

Câu trả lời cho câu hỏi phỏng vấn này dựa trên bài viết của Hoàng tử thứ ba Ao Bing: Người phỏng vấn của Alibaba hỏi tôi: Làm thế nào để thiết kế một hệ thống bán hàng chớp nhoáng? Tôi đã đưa ra một câu trả lời gần đạt điểm tối đa.

Hệ thống flash kill cần giải quyết những vấn đề gì?

① Tính đồng thời cao

Đặc điểm của flash sale là thời gian cực ngắn và số lượng người dùng lớn ngay lập tức. Trong thời gian diễn ra sự kiện flash sale, máy chủ Redis cần phải đáp ứng một số lượng lớn yêu cầu của người dùng. Dưới một số lượng lớn yêu cầu, các vấn đề như lỗi bộ nhớ đệm, sự cố bộ nhớ đệm và thâm nhập bộ nhớ đệm có thể xảy ra.

Khi bộ đệm bị lỗi hoặc bộ đệm không hợp lệ, hàng chục nghìn hoặc thậm chí hàng trăm nghìn QPS (yêu cầu mỗi giây) mỗi giây sẽ được truy cập trực tiếp vào cơ sở dữ liệu, về cơ bản, cơ sở dữ liệu sẽ bị tắt và dịch vụ của bạn không chỉ là một bán flash mà còn bán flash. Khi nói đến các doanh nghiệp khác, nếu bạn chưa thực hiện bất kỳ việc hạ cấp, giới hạn dòng điện, ngắt mạch, v.v., thì những thứ khác sẽ không hoạt động. Nếu đó là một công ty nhỏ, toàn bộ trang web có thể ngừng hoạt động. gặp sự cố với 404.

Vì lý do này, khi thiết kế hệ thống flash sale, trước tiên chúng ta phải xem xét tính bảo mật đồng thời và hiệu quả truy cập của người dùng, cả hai đều không thể thiếu! .

② Bán quá mức

Khi nói đến vấn đề mua sản phẩm và mua sắm flash sale, điều quan trọng nhất cần chú ý là vấn đề bán quá mức, bởi vì một khi vấn đề bán quá mức xảy ra do thủ tục không an toàn, người bán không chỉ phải bồi thường thiệt hại mà còn phải bồi thường thiệt hại. Nhà phát triển hệ thống flash sale cũng phải chịu trách nhiệm! .

③Yêu cầu độc hại

Trong quá trình mua sắm giảm giá chớp nhoáng, giá sản phẩm tương đối thấp và một số bên thứ ba độc hại có thể sử dụng các sản phẩm có giá trị cao để chạy nhiều máy nhằm thực thi các tập lệnh chụp nhanh trên máy chắc chắn nhanh hơn so với các lần nhấp chuột thủ công của chúng tôi. thiết kế hệ thống bán hàng chớp nhoáng Khi làm như vậy, chúng ta phải ngăn chặn những kẻ lập trình độc hại chộp lấy.

④ Hiển thị liên kết

Nếu tính năng bán hàng flash theo lịch trình được đặt thành bật, nút mua đơn hàng sẽ bị tắt (không thể nhấp) trước thời gian mở bán flash. Tuy nhiên, nếu liên kết chúng tôi yêu cầu đặt hàng không được mã hóa bởi cổng mà trực tiếp trong cổng. dạng liên kết ban đầu Được đính kèm với nút mua hàng, khi nhấn F12, bạn có thể lấy URL liên kết mua hàng, sau đó trực tiếp yêu cầu liên kết đặt hàng, bỏ qua phương thức nhấp chuột và mua sản phẩm trực tiếp! .

Làm thế nào để giải quyết những vấn đề gặp phải trên?

① Mô-đun flash sale dựa trên microservice

Đối với hệ thống flash sale, hãy thiết kế nó thành một mô-đun riêng biệt và triển khai một hoặc nhiều máy chủ riêng biệt, điều này có thể tránh được sự cố dịch vụ và các dự án khác của công ty có thể chạy bình thường mà không bị ảnh hưởng.

Đồng thời, cần thiết lập cơ sở dữ liệu riêng cho hệ thống flash sale. Việc triển khai kiến ​​trúc Internet hiện nay được chia thành các cơ sở dữ liệu. Tương tự, dịch vụ đặt hàng tương ứng với cơ sở dữ liệu đặt hàng đối với flash sale. sở hữu cơ sở dữ liệu flash sale cho nó để ngăn chặn sự cố dịch vụ ảnh hưởng đến các cơ sở dữ liệu khác.

② Thêm muối vào link flash kill

URL là động và một chuỗi ngẫu nhiên được mã hóa bằng thuật toán mã hóa như MD5 để tạo URL, sau đó URL được lấy thông qua mã giao diện người dùng và có thể được chuyển sau khi xác minh lý lịch.

③ Cụm Redis

Nếu Redis một máy không chịu được lượng yêu cầu lớn thì tìm thêm vài anh em flash sale ban đầu là đọc nhiều viết ít thông qua cụm Redis, đồng bộ hóa master-slave, tách đọc ghi, cộng với canh gác. cho phép tính bền bỉ, để đảm bảo tính sẵn sàng cao của dịch vụ Redis! .

④ Cân bằng tải qua Nginx

Nginx là một máy chủ web hiệu suất cao. Việc hỗ trợ hàng chục nghìn đồng thời không phải là điều mơ ước. Tuy nhiên, Tomcat của chúng tôi chỉ có thể hỗ trợ vài trăm đồng thời. Chúng tôi có thể sử dụng cân bằng tải Nginx để phân phối đồng đều các yêu cầu đồng thời lớn cho Tomcat. máy chủ Trong đợt giảm giá chớp nhoáng Khi nó được bật, bạn có thể thuê thêm máy lưu lượng truy cập.

⑤ Tĩnh hóa tài nguyên trang flash sale

Bán hàng flash thường liên quan đến các sản phẩm và mẫu trang cụ thể. Ngày nay, front-end và back-end thường được tách biệt nên trang thường không đi qua back-end, nhưng front-end cũng cần có máy chủ riêng. có thể đặt trước** Đặt tất cả nội dung của máy chủ cdn** vào đó. Dù sao, hãy thực hiện tất cả các bước có thể nâng cao hiệu quả để giảm áp lực cho máy chủ trong thời gian flash sale thực sự.

⑥ Kiểm soát nút đặt hàng

Trước khi chương trình khuyến mại chớp nhoáng bắt đầu, nút đặt hàng thường có màu xám và chỉ có thể nhấp vào khi hết thời gian. Điều này là do chúng tôi sợ rằng mọi người sẽ đưa ra những yêu cầu điên rồ tới máy chủ trong vài giây cuối cùng trước khi hết thời gian và sau đó về cơ bản máy chủ sẽ cúp máy trước đợt giảm giá chớp nhoáng.

Tại thời điểm này, bạn cần sự hợp tác của giao diện người dùng để thường xuyên yêu cầu máy chủ phụ trợ của bạn lấy giờ Bắc Kinh mới nhất, sau đó cung cấp cho nút trạng thái khả dụng tại thời điểm đó. Sau khi có thể nhấp vào nút, nút này phải chuyển sang màu xám trong vài giây, nếu không nút sẽ tiếp tục nhấp sau khi bắt đầu.

⑦ Giới hạn dòng điện mặt trước và mặt sau

Giới hạn dòng điện có thể được chia thành giới hạn dòng điện phía trước và giới hạn dòng điện phía sau.

Giới hạn dòng điện phía trước: Điều này rất đơn giản. Nói chung, nút đặt hàng sẽ không khiến bạn nhấp vào. Nói chung, bạn nhấp một hoặc hai lần và sau đó bạn có thể tiếp tục nhấp vào. Đây cũng là một phương tiện. bảo vệ máy chủ.

Giới hạn hiện tại ở phía sau: Việc bán flash chắc chắn liên quan đến các hoạt động thanh toán và tạo đơn hàng tiếp theo, nhưng chỉ những người may mắn thành công mới đi đến bước đó. Sau khi bán hết 100 sản phẩm, một sản phẩm giả sẽ được trả lại và giao diện người dùng Flash. việc bán hàng kết thúc trực tiếp và sau đó chương trình phụ trợ của bạn cũng sẽ chấm dứt sự can thiệp của các yêu cầu không hợp lệ tiếp theo.

⑧ Khởi động hàng tồn kho

Bản chất của bán hàng chớp nhoáng là cướp hàng tồn kho. Nếu mọi người dùng đặt hàng flash sale yêu cầu, họ sẽ đến cơ sở dữ liệu để truy vấn hàng tồn kho, xác minh hàng tồn kho và sau đó khấu trừ hàng tồn kho. Điều này không những không hiệu quả mà còn gây áp lực rất lớn cho cơ sở dữ liệu! .

Vì cơ sở dữ liệu không thể chịu được nó nên cơ sở dữ liệu phi quan hệ Redis của anh em nó có thể! .

Vấn đề bán quá mức:

Trước khi bắt đầu chương trình giảm giá chớp nhoáng, chúng ta cần tải trước hàng tồn kho sản phẩm vào Redis thông qua các tác vụ đã lên lịch để toàn bộ quy trình xác minh hàng tồn kho được thực hiện trong Redis, sau đó đợi cho đến khi sự kiện bán hàng chớp nhoáng kết thúc, sau đó sửa đổi hàng tồn kho một cách không đồng bộ trong cơ sở dữ liệu được rồi.

Nhưng có một vấn đề khi sử dụng Redis. Như chúng tôi đã nói ở trên, chúng tôi sử dụng Redis master-slave, tức là trước tiên chúng tôi sẽ đọc khoảng không quảng cáo, sau đó đánh giá khoảng không quảng cáo và giảm bớt khoảng không quảng cáo khi có khoảng không quảng cáo. không có vấn đề gì, nhưng các tình huống có tính đồng thời cao sẽ rất có vấn đề.

Ví dụ: chỉ còn 1 chiếc trong kho. Do tính đồng thời cao của chúng tôi, 4 máy chủ đã truy vấn và thấy rằng vẫn còn 1 chiếc. Sau đó mọi người đều nghĩ rằng họ đã lấy được nên tất cả đều trừ đi hàng tồn kho và kết quả là. -3. Trong trường hợp này, chỉ có một yêu cầu thực sự nhận được sản phẩm và ba yêu cầu còn lại đều đã bán quá mức.

Làm thế nào để giải quyết nó?

Vấn đề bán quá mức có thể được giải quyết bằng cách sử dụng tập lệnh Lua.

**Các tập lệnh Lua tương tự như các giao dịch Redis, có tính nguyên tử nhất định, sẽ không bị các lệnh khác xếp hàng và có thể hoàn thành một số hoạt động giao dịch Redis. **Đây là chìa khóa! .

Viết các thao tác xác định hàng tồn kho và khấu trừ hàng tồn kho bằng tập lệnh Lua và giao tập lệnh cho Redis để thực thi. Khi số lượng hàng tồn kho trong Redis giảm xuống 0, các yêu cầu khấu trừ hàng tồn kho tiếp theo sẽ trực tiếp trả về sai.

⑨ Giới hạn hiện tại & hạ cấp & hợp nhất & cách ly

Đừng sợ 10.000, chỉ sợ một tình huống xảy ra nếu hệ thống tiêu diệt ngay lập tức thực sự không thể chịu đựng được, hãy hạn chế dòng chảy nếu nó không thể chịu đựng được, chỉ cần chặn một số trong đó. Nhưng bạn không thể nói không, hạ cấp thì vẫn bị chặn. chết đi đừng kéo anh em xuống nữa.

2. Người phỏng vấn: Bạn đã bao giờ hiểu rõ về mã nguồn AQS chưa? Bạn có thể vui lòng cho tôi biết quy trình khóa và mở khóa không?

Câu trả lời cho câu hỏi phỏng vấn này dựa trên bài viết của Tam hoàng tử Ao Bing: Tôi đã vẽ 35 bức tranh chỉ để bạn tìm hiểu thêm về AQS.

① Giới thiệu AQS

Bảo trì trong AQS về cơ bản giới thiệu trạng thái int dễ bay hơi (đại diện cho tài nguyên được chia sẻ) và hàng đợi luồng FIFO (hàng đợi này sẽ được nhập khi nhiều luồng cạnh tranh tài nguyên và bị chặn).

Ở đây, tính dễ bay hơi có thể đảm bảo khả năng hiển thị trong nhiều luồng. Khi trạng thái = 1, điều đó có nghĩa là khóa đối tượng hiện tại đã bị chiếm. Khi các luồng khác cố gắng khóa, chúng sẽ không khóa được. queue. Và nó sẽ bị treo bởi hoạt động UNSAFE.park(), chờ các luồng khác đã lấy được khóa giải phóng khóa trước khi nó có thể được đánh thức.

Ngoài ra, các hoạt động trạng thái được thực hiện thông qua CAS để đảm bảo an toàn cho các sửa đổi đồng thời.

Như thể hiện trong hình ảnh:

AQS cung cấp nhiều phương pháp triển khai khóa:

getState(): Lấy giá trị trạng thái cờ của khóa.

setState(): Đặt giá trị trạng thái cờ khóa.

tryAcquire(int): Chỉ lấy khóa. Cố gắng lấy tài nguyên, trả về true nếu thành công và false nếu thất bại.

tryRelease(int): Giải phóng khóa riêng. Cố gắng giải phóng tài nguyên, trả về true nếu thành công và false nếu thất bại.

② Phân tích các kịch bản sử dụng khóa và khóa cạnh tranh

Nếu có ba luồng đồng thời chiếm giữ khóa, thì luồng một thành công trong việc chiếm giữ khóa, nhưng luồng hai và ba không chiếm được khóa. Quá trình thực hiện cụ thể như sau:

Tại thời điểm này, dữ liệu nội bộ của AQS là:

Cụ thể, hãy xem cách triển khai mã khóa ưu tiên: java.util.concurrent.locks.ReentrantLock .NonfairSync.

1. tĩnh cuối cùng lớp học Không đồng bộ mở rộng Đồng bộ {
2. // khóa
3. cuối cùng vô hiệu khóa() {
4. // CAS sửa đổi giá trị của state thành 1
5. nếu như (so sánhAndSetState(0, 1))
6. setExclusiveOwnerThread(Chủ đề.hiện tạiThread());
7. khác
8. giành được(1);
9. }
10. // Cố gắng tranh giành tài nguyên
11. được bảo vệ cuối cùng Boolean thửThu thập(số nguyên có được) {
12. trở lại không công bằngThửCó được(có được);
13. }
14. }

ReentrantLock được sử dụng ở đây là một khóa không công bằng. Chuỗi đi vào và trực tiếp sử dụng CAS để cố gắng chiếm lấy khóa. Nếu quyền ưu tiên thành công, giá trị trạng thái được thay đổi thành 1 và đối tượng chuỗi khóa độc quyền được đặt thành chuỗi hiện tại. .

1. // CAS cố gắng chiếm lấy khóa
2. được bảo vệ cuối cùng Boolean so sánhAndSetState(số nguyên trông chờ, số nguyên cập nhật) {
3. trở lại không an toàn.so sánh và hoán đổi(cái này, trạng thái Offset, trông chờ, cập nhật);
4. }
5. // Đặt đối tượng luồng khóa độc quyền cho luồng hiện tại
6. được bảo vệ cuối cùng vô hiệu setExclusiveOwnerThread(Chủ đề chủ đề) {
7. exclusiveOwnerThread = chủ đề;
8. }

Sau khi luồng một chiếm khóa thành công, trạng thái sẽ thay đổi thành 1. Luồng hai chắc chắn sẽ không sửa đổi được biến trạng thái thông qua CAS. Tại thời điểm này, nó nằm trong hàng đợi FIFO (Vào trước ra trước) trong AQS.

1. công cộng cuối cùng vô hiệu giành được(số nguyên tranh luận) {
2. nếu như (!thửThu thập(tranh luận) &&
3. thu thậpĐã xếp hàng(thêmNgười phục vụ(Nút.LOẠI TRỪ), tranh luận))
4. tự ngắt();
5. }

Cách triển khai cụ thể của phương thức tryAcquire() là gọi nội bộ phương thức nonfairTryAcquire(). Logic thực thi của phương thức này như sau:

Đầu tiên, giá trị trạng thái sẽ được lấy. Nếu nó không bằng 0, điều đó có nghĩa là khóa của đối tượng hiện tại đã bị các luồng khác chiếm giữ.

Sau đó, nó được xác định xem luồng đang giữ khóa có phải là luồng hiện tại hay không. Nếu vậy, giá trị trạng thái sẽ được tích lũy. Đây là cách triển khai cụ thể của khóa đăng ký lại và giá trị trạng thái cũng bị giảm khi khóa. được phát hành.

Nếu trạng thái là 0, hãy thực hiện thao tác CAS và cố gắng cập nhật giá trị trạng thái thành 1. Nếu cập nhật thành công, điều đó có nghĩa là luồng hiện tại đã được khóa thành công.

③ Phân tích các kịch bản sử dụng khóa phát hành

Quá trình giải phóng khóa bắt đầu bằng luồng một giải phóng khóa, sau khi giải phóng khóa, nó sẽ đánh thức nút hậu của nút đầu, đây là luồng hai hiện tại của chúng tôi. Quá trình hoạt động cụ thể như sau:

Sau khi thực hiện, dữ liệu hàng đợi chờ như sau:

Tại thời điểm này, luồng thứ hai đã được đánh thức và tiếp tục cố gắng lấy khóa. Nếu không lấy được khóa, nó sẽ tiếp tục bị treo.

Mã cho khóa giải phóng chủ đề:

java.util.concurrent.locks.AbstractQueuedSynchronizer.release():

1. công cộng cuối cùng Boolean giải phóng(số nguyên tranh luận) {
2. nếu như (thửPhát hành(tranh luận)) {
3. Nút h = cái đầu;
4. nếu như (h != vô giá trị && h.chờTrạng thái != 0)
5. unparkNgười kế nhiệm(h);
6. trở lại ĐÚNG VẬY;
7. }
8. trở lại SAI;
9. }

Ở đây, phương thức tryRelease() trước tiên sẽ được thực thi. Phương thức này được triển khai cụ thể trong ReentrantLock. Nếu tryRelease() được thực thi thành công, nó sẽ tiếp tục xác định xem waitStatus của nút đầu có bằng 0 hay không. của head là SIGNAL(-1 ), phương thức unparkSuccessor() sẽ được thực thi tại đây để đánh thức post-node của head, chính là node Node tương ứng với thread 2 trong hình trên.

Khóa khởi động lại.tryRelease():

1. được bảo vệ cuối cùng Boolean thửPhát hành(số nguyên phát hành) {
2. số nguyên c = lấyTrạng Thái() - phát hành;
3. nếu như (Chủ đề.hiện tạiThread() != lấy chủ sở hữu độc quyềnThread())
4. ném mới Ngoại lệ IllegalMonitorStateException();
5. Boolean miễn phí = SAI;
6. nếu như (c == 0) {
7. miễn phí = ĐÚNG VẬY;
8. setExclusiveOwnerThread(vô giá trị);
9. }
10. setState(c);
11. trở lại miễn phí;
12. }

Sau khi thực thi ReentrantLock.tryRelease(), trạng thái được đặt thành 0 và khóa độc quyền của đối tượng Khóa được đặt thành null.

Sau đó thực thi phương thức java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor() để đánh thức post-node của head:

1. riêng tư vô hiệu unparkNgười kế nhiệm(Nút nút) {
2. số nguyên chúng ta = nút.chờTrạng thái;
3. nếu như (chúng ta < 0)
4. so sánhAndSetWaitStatus(nút, chúng ta, 0);
5. Nút S = nút.Kế tiếp;
6. nếu như (S == vô giá trị || S.chờTrạng thái > 0) {
7. S = vô giá trị;
8. vì (Nút t = đuôi; t != vô giá trị && t != nút; t = t.trước đó)
9. nếu như (t.chờTrạng thái <= 0)
10. S = t;
11. }
12. nếu như (S != vô giá trị)
13. KhóaHỗ trợ.bỏ đậu xe(S.chủ đề);
14. }

Điều chính ở đây là đặt waitStatus của nút đầu thành 0, sau đó loại bỏ con trỏ tiếp theo của nút đầu, để trống nút đầu, chờ thu gom rác.

Tại thời điểm này, hãy trỏ lại con trỏ head tới nút Node tương ứng với luồng hai và sử dụng phương thức LockSupport.unpark để đánh thức luồng hai.

Sau đó, luồng 2 được đánh thức sẽ cố gắng lấy khóa và sử dụng lệnh CAS để sửa đổi dữ liệu trạng thái.

3. Người phỏng vấn: Xin ông cho biết nguyên tắc thực hiện đồng bộ?

Câu trả lời cho câu hỏi phỏng vấn này tham khảo bài viết: Phân tích đồng bộ chuỗi đồng bộ hóa Java.

Phân tích nguyên tắc khóa và mở khóa đồng bộ

Khóa đồng bộ, ở cấp mô hình bộ nhớ Java, bao gồm 2 lệnh (JMM định nghĩa 8 thao tác để hoàn thành sự tương tác giữa bộ nhớ chính và bộ nhớ làm việc. Bài viết tham khảo: Sau khi thu thập nhiều thông tin như vậy, tôi không tin bạn vẫn không thể hiểu được mô hình bộ nhớ JMM, Từ khóa dễ bay hơi đảm bảo nguyên tắc triển khai thứ tự và khả năng hiển thị), khóa và mở khóa:

• khóa, khóa, tác động lên các biến trong bộ nhớ chính, xác định các biến trong bộ nhớ chính là trạng thái chỉ có luồng.
• mở khóa, mở khóa, tác động lên các biến trong bộ nhớ chính. Nó giải phóng các biến bị khóa để các biến được giải phóng có thể bị khóa bởi các luồng khác.

Hai hướng dẫn này không được cung cấp trực tiếp cho người dùng, nhưng hai hướng dẫn cấp cao hơn Monitorenter và Monitorexit được cung cấp để sử dụng ngầm các hướng dẫn khóa và mở khóa. Đồng bộ hóa được thực hiện bằng cách sử dụng hai lệnh giám sát và màn hình thoát.

Theo yêu cầu của đặc tả JVM, khi thực hiện lệnh của trình giám sát, trước tiên bạn phải cố gắng lấy khóa của đối tượng. Nếu đối tượng không bị khóa hoặc luồng hiện tại đã sở hữu khóa của đối tượng thì bộ đếm khóa sẽ bị khóa. tăng thêm 1 và theo đó, khi màn hìnhexit được thực thi, bộ đếm sẽ giảm đi 1. Khi bộ đếm giảm về 0, khóa sẽ được giải phóng.

Khóa đồng bộ hóa đảm bảo tính nguyên tử, khả năng hiển thị và tính nhất quán như thế nào?

Quay trở lại mô hình bộ nhớ Java, lớp dưới cùng của từ khóa được đồng bộ hóa được triển khai thông qua màn hình và màn hình, và hai hướng dẫn này được triển khai thông qua khóa và mở khóa.

Khóa và mở khóa phải đáp ứng bốn quy tắc sau trong mô hình bộ nhớ Java:

• ① Chỉ một luồng được phép truy cập một biến cùng một lúc. khóa hoạt động nhưng khóa Các hoạt động có thể được thực hiện nhiều lần bởi cùng một luồng và được thực hiện nhiều lần khóa Sau đó, chỉ có cùng số lần thực hiện mở khóa Hoạt động, biến có thể được mở khóa.
• ② Nếu được thực thi trên một biến khóa Thao tác sẽ xóa giá trị của biến này trong bộ nhớ làm việc trước khi công cụ thực thi sử dụng biến này, nó cần được thực thi lại. trọng tải hoặc giao phó Vận hành giá trị của biến khởi tạo;
• ③ Nếu một biến không khóa Nếu thao tác bị khóa thì không được phép thực thi mở khóa Hoạt động không được phép mở khóa Một biến bị khóa bởi một luồng khác;
• ④ Thực thi trên một biến mở khóa Trước khi hoạt động, biến này phải được đồng bộ trở lại bộ nhớ chính, nghĩa là thực thi cửa hàng Và viết vận hành;

Thông qua quy tắc ①, chúng ta biết rằng chỉ có một luồng được phép truy cập mã giữa khóa và mở khóa cùng một lúc, do đó, đồng bộ hóa là nguyên tử.

Thông qua quy tắc ① ② và ④, chúng ta biết rằng các biến sẽ được tải từ bộ nhớ chính hoặc được làm mới trở lại bộ nhớ chính mỗi khi thực hiện khóa và mở khóa, còn các biến giữa khóa và mở khóa (ở đây đề cập đến các biến bị khóa) sẽ không được sử dụng bởi người khác Được sửa đổi theo luồng, do đó, đồng bộ hóa sẽ hiển thị.

Thông qua quy tắc ① và ③, chúng ta biết rằng tất cả các khóa trên các biến phải được xếp hàng đợi và các luồng khác không được phép mở khóa các đối tượng bị khóa bởi luồng hiện tại, do đó việc đồng bộ hóa có trật tự.

Tóm lại, đồng bộ hóa có thể đảm bảo tính nguyên tử, khả năng hiển thị và tính ngăn nắp.

tối ưu hóa khóa đồng bộ

Java không ngừng phát triển Tương tự, các từ khóa như được đồng bộ hóa trong Java cũng liên tục được tối ưu hóa có ba trạng thái sau:

• khóa thiên vị, có nghĩa là một đoạn mã đồng bộ hóa đã được một luồng truy cập, khi đó luồng này sẽ tự động lấy được khóa, giảm chi phí lấy được khóa.
• khóa nhẹ, có nghĩa là khi khóa là khóa thiên vị và được truy cập bởi một luồng khác, khóa thiên vị sẽ được nâng cấp lên khóa nhẹ. Chuỗi này sẽ cố gắng lấy khóa bằng cách quay mà không chặn, cải thiện hiệu suất.
• Khóa nặng, nghĩa là khi khóa là khóa nhẹ, khi sợi quay đã quay một số lần nhất định mà chưa thu được khóa thì sẽ chuyển sang trạng thái chặn. sẽ khiến các luồng khác bị chặn và hiệu suất bị giảm.

Tóm tắt.

(1) được đồng bộ hóa sẽ tạo ra các hướng dẫn mã byte màn hình và màn hình trước và sau khối đồng bộ hóa trong quá trình biên dịch;.

(2) Các hướng dẫn mã byte màn hình và màn hình xuất cảnh yêu cầu tham số thuộc loại tham chiếu, không phải loại cơ bản;

(3) Cấp độ thấp hơn của các hướng dẫn mã byte màn hình và màn hình xuất là các hướng dẫn khóa và mở khóa bằng mô hình bộ nhớ Java;.

(4) đồng bộ hóa là khóa đăng ký lại;

(5) đồng bộ hóa là một khóa không công bằng;

(6) đồng bộ hóa có thể đồng thời đảm bảo tính nguyên tử, khả năng hiển thị và trật tự;

(7) đồng bộ hóa có ba trạng thái: khóa thiên vị, khóa nhẹ và khóa nặng;.

Bài viết này kết thúc tại đây, tôi hy vọng nó có thể hữu ích cho bạn và tôi hy vọng bạn có thể chú ý hơn đến nội dung của chúng tôi! .

Liên kết gốc: https://csp1999.blog.csdn.net/article/details/118116777.

Cuối cùng, bài viết này về tóm tắt cuộc phỏng vấn: thiết kế flash sale, AQS, các vấn đề liên quan được đồng bộ hóa sẽ kết thúc tại đây. Nếu bạn muốn biết thêm về tóm tắt cuộc phỏng vấn: thiết kế flash sale, AQS, các vấn đề liên quan được đồng bộ hóa, vui lòng tìm kiếm bài viết CFSDN hoặc tiếp tục Duyệt các bài viết liên quan. , Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .