CN111459462B

CN111459462B - Decentralized relock demotion

Info

Publication number: CN111459462B
Application number: CN201910050640.6A
Authority: CN
Inventors: 杨启彬; 秦巍; 张斌; 赵俊民; 朱金鹏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-01-20
Filing date: 2019-01-20
Publication date: 2023-05-09
Anticipated expiration: 2039-01-20
Also published as: WO2020147859A1; CN111459462A

Abstract

Embodiments of the present application provide a lock operation method running on an electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a lock of the first object of the first thread Cheng Chiyou, the lock including a lock word recording a state of the lock, the lock operation method including executing without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, judging whether other threads wait for the lock of the first object under the condition that the lock of the first object is a reslock; and 3, judging in the step 2 that no other thread demotes the lock of the first object under the condition of waiting for the lock of the first object.

Description

Decentralized relock demotion

Technical Field

The present invention relates to the field of computers, and more particularly, to a lock operation method and an electronic device that runs the lock operation method.

Background

Java language is widely used, for example, in a J2 EE-based web service, in an android (android) operating system commonly used in a mobile terminal, in application software that can run on the android operating system or ios operating system, in a rich client application (rich client application), etc., the Java language can be used for development, so that the software can run in a Java running environment.

One feature of Java is to support parallel running (parallel processing), also known as concurrency, i.e., there are multiple programs or threads simultaneously within a time period, some of which may have to access the same resource, e.g., the same object, thereby creating a race. To ensure orderly execution, java provides an object-based lock (lock) mechanism in which only one thread can hold a lock at a time, and only after the thread releases the lock, the other thread may hold the lock of the object and execute the program code contained in the object. One type of lock used in more aggressive situations is called a livelock (fat) which results in more system calls and thus greater overhead. And once the object has a re-lock, the object is not revoked by a thread take (obtain) lock and release (release) lock. In other words, these objects will always be weight-locked without special intervention, with the number of relocked objects increasing and the number of times they are accessed during their lifecycle accumulating, the accompanying system calls placing a greater burden on the system. While some of the objects may no longer be in a contended state after having a relock, which is no longer necessary. It can be seen that a lock degradation (deflating) mechanism is needed to degrade the unnecessary presence of the locks, so as to reduce the burden of the system and improve the operation efficiency.

Currently, the ART (android runtime) virtual machine developed by google corporation provides a lock downgrade mechanism that is attached to garbage collection (garbage collection, GC). The GC pauses the runtime, i.e., pauses threads created by the application. The mode of centralized lock degradation during GC can not solve the problem of unnecessary system burden caused by double locking between two GCs on one hand, and on the other hand, the pause of threads during GC brings a clamping experience to a user (according to different GC cleaning ranges, the time consumption of single GC can reach hundreds of milliseconds). Pausing the virtual machine is therefore undesirable from the standpoint of ensuring a smooth user experience, while a GC that is too long interval is inefficient from the standpoint of lock degradation.

Disclosure of Invention

The embodiment of the application provides a distributed lock downgrade mechanism, wherein the lock downgrade time is independent of GC, and when a currently-held lock thread releases a lock again, if the lock is detected not to be in competition any more, the lock is downgraded in time. The degradation of the primary lock takes nanoseconds and cannot be perceived by a user. Therefore, the distributed lock degradation mechanism ensures that the fluency experience of a user is not influenced by lock degradation, and avoids unnecessary re-lock expenditure in time.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical scheme:

in a first aspect, a lock operation method is provided, the lock operation method running on an electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a first thread Cheng Chiyou of a lock of the first object, the lock including a lock word (lockword) that records a state of the lock, the lock operation method including performing without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, judging whether other threads wait for the lock of the first object under the condition that the lock of the first object is a reslock; and 3, judging in the step 2 that no other thread demotes the lock of the first object under the condition of waiting for the lock of the first object. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread releases the lock in the MonitorExit module before exiting the protected code segment. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock.

In some implementations, demoting the lock of the first object includes converting the lock of the first object to a light lock and converting to no lock.

In some embodiments, steps 1, 2 and 3 are performed in a MonitorExit module.

In some embodiments, the condition in step 3 that no other thread is waiting for the lock of the first object is that there is no Java Method for wait, sleep, etc., nor is there a conflict state, which refers to other threads that are ready to block on the lock.

In some embodiments, the lock operation method further comprises executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is degraded to be free of lock in the step 5, enabling the first thread to read the lock state again aiming at the lock of the first object and to walk the corresponding free-lock flow; step 7, under the condition that the lock is not degraded to be lock-free in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object should walk when its state is lock-free. It is common for a thread to acquire a lock and change lock-free to a light lock by placing its own identification into a lock word (lockword). The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, if it is found that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, T2 will set the conflict flag, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection, so that other threads except T2 can not enter the spin lock protected code blocks temporarily, the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In some embodiments, the lock operation method further comprises: in step 2, it is also checked whether the lock word of the first object lock is a hash code; in step 3, if it is determined in step 2 that no other thread waits for the lock of the first object and the lock word is not a hash code, checking whether the reslock conflict flag is 0, and if it is 0, downgrading the lock of the first object to no lock.

In a second aspect, a lock operation method is provided, the lock operation method running on an electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a lock of the first object on the first line Cheng Chiyou, the lock including a lock word (lockword) recording a state of the lock, the lock operation method including executing without suspending the first thread: step 1, checking whether the reentry times is 0; step 2, under the condition that the reentry times are 0 in the step 1, degrading the first object lock to be lock-free under the condition that the reentry conflict mark is 0; and 3, under the condition that the reentrant times are not 0 in the step 1, degrading the first object lock into a light lock under the condition that the conflict sign of the heavy lock is 0. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread may enter the MonitorExit module before running the code to release the lock. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock. The number of reentrants records the total number of times thread T1 entered the monitor enter module of the current object without releasing the lock.

In some embodiments, steps 1, 2 and 3 are performed in a MonitorExit module.

In some embodiments, the lock operation method further comprises executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is judged to be degraded in step 5, the lock state is obtained again, and the lock state is possibly lock-free or light; step 7, under the condition that the lock is not degraded in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, if it is found that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, T2 will set the conflict flag, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection, so that other threads except T2 can not enter the spin lock protected code blocks temporarily, the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In a third aspect, there is provided an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the computer program, causes the electronic device to carry out the lock operation method of any implementation form of the first and second aspects of the present application.

In some embodiments, an electronic device implements a lock operation method running on the electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a lock of the first object of the first thread Cheng Chiyou, the lock including a lock word (lockword) that records a state of the lock, the lock operation method including performing without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, judging whether other threads wait for the lock of the first object under the condition that the lock of the first object is a reslock; and 3, judging in the step 2 that no other thread demotes the lock of the first object under the condition of waiting for the lock of the first object. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread may enter the MonitorExit module before running the code to release the lock. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock.

In some implementations, in an electronic device implemented lock operation method, downgrading a lock of a first object includes converting the lock of the first object to a light lock and to no lock.

In some embodiments, in the lock operation method implemented by the electronic device, step 1, step 2 and step 3 are performed in a MonitorExit module.

In some embodiments, in the lock operation Method implemented by the electronic device, the condition that no other thread waits for the lock of the first object in step 3 is that there is no Java Method for wait, sleep, etc., and there is no conflict state, where the conflict state refers to that the other thread is ready to block on the lock.

In some embodiments, the lock operation method implemented in the electronic device further includes executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is degraded to be free in the step 5, enabling the first thread to walk the free-lock flow aiming at the lock of the first object; step 7, under the condition that the lock is not degraded to be lock-free in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object should walk when its state is lock-free. It is common for a thread to acquire a lock and change lock-free to a light lock by placing its own identification into a lock word (lockword). The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, if it is found that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, T2 will set the conflict flag, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection so that other threads except T2 can not enter the spin lock protected code blocks temporarily, wherein the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In some embodiments, the lock operation method implemented in the electronic device further includes: in step 2, it is also checked whether the lock word of the first object lock is a hash code; in step 3, if it is determined in step 2 that no other thread waits for the lock of the first object and the lock word is not a hash code, checking whether the reslock conflict flag is 0, and if it is 0, downgrading the lock of the first object to no lock.

Alternatively, the electronic device according to the third aspect implements the following lock operation method:

an electronic device implements a lock operation method that runs on an electronic device on which a first object is arranged, the first object being a piece of code, and on which at least one application is arranged, the at least one application having a first thread, a lock of the first object of a first thread Cheng Chiyou, the lock including a lock word (lockword) that records a state of the lock, the lock operation method including executing without suspending the first thread: step 1, checking whether the reentry times is 0; step 2, under the condition that the reentry times are 0 in the step 1, degrading the first object lock to be lock-free under the condition that the reentry conflict mark is 0; and 3, under the condition that the reentrant times are not 0 in the step 1, degrading the first object lock into a light lock under the condition that the conflict sign of the heavy lock is 0. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread may enter the MonitorExit module before running the code to release the lock. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock. The number of reentrants records the total number of times thread T1 entered the monitor enter module of the current object without releasing the lock.

In some embodiments, the lock operation method implemented in the electronic device further includes executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is judged to be degraded in step 5, the lock state is read again, and the lock state is possibly light lock or no lock; step 7, under the condition that the lock is not degraded in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, if it is found that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, T2 will set the conflict flag, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection so that other threads except T2 can not enter the spin lock protected code blocks temporarily, wherein the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In a fourth aspect, there is provided a computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the lock operation method of any of the implementation forms of the first and second aspects of the present application.

In some embodiments, an electronic device performs a lock operation method running on the electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a lock of the first object of the first thread Cheng Chiyou, the lock including a lock word (lockword) that records a state of the lock, the lock operation method including performing without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, judging whether other threads wait for the lock of the first object under the condition that the lock of the first object is a reslock; and 3, judging in the step 2 that no other thread demotes the lock of the first object under the condition of waiting for the lock of the first object. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread may enter the MonitorExit module before running the code to release the lock. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock.

In some implementations, in a method of lock operation performed by an electronic device, demoting a lock of a first object includes converting the lock of the first object to a light lock and converting to no lock.

In some embodiments, in the lock operation method executed by the electronic device, step 1, step 2 and step 3 are executed in a MonitorExit module.

In some embodiments, in the lock operation Method executed by the electronic device, the condition that no other thread waits for the lock of the first object in step 3 is that there is no Java Method for wait, sleep, etc., and there is no conflict state, where the conflict state refers to that the other thread is ready to block on the lock.

In some embodiments, the lock operation method executed in the electronic device further includes executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is degraded to be free in the step 5, enabling the first thread to walk the free-lock flow aiming at the lock of the first object; step 7, under the condition that the lock is not degraded to be lock-free in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object should walk when its state is lock-free. It is common for a thread to acquire a lock and change lock-free to a light lock by placing its own identification into a lock word (lockword). The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, T2 will set the conflict flag if it is found at this time that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection so that other threads except T2 can not enter the spin lock protected code blocks temporarily, wherein the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In some embodiments, the lock operation method executed by the electronic device further includes: in step 2, it is also checked whether the lock word of the first object lock is a hash code; in step 3, if it is determined in step 2 that no other thread waits for the lock of the first object and the lock word is not a hash code, checking whether the reslock conflict flag is 0, and if it is 0, downgrading the lock of the first object to no lock.

Alternatively, the electronic device according to the third aspect performs the following lock operation method:

an electronic device executing a lock operation method, the lock operation method running on the electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, a first thread Cheng Chiyou of a lock of the first object, the lock including a lock word (lockword) recording a state of the lock, the lock operation method comprising executing without suspending the first thread: step 1, checking whether the reentry times is 0; step 2, under the condition that the reentry times are 0 in the step 1, degrading the first object lock to be lock-free under the condition that the reentry conflict mark is 0; and 3, under the condition that the reentrant times are not 0 in the step 1, degrading the first object lock into a light lock under the condition that the conflict sign of the heavy lock is 0. In operation, a program in java language may modify an object with a synchronized key, for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread may enter the MonitorExit module before running the code to release the lock. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment. The lock states include heavy lock, light lock and no lock. The number of reentrants records the total number of times thread T1 entered the monitor enter module of the current object without releasing the lock.

In some embodiments, the lock operation method executed in the electronic device further includes executing in a monitor enter module: step 4, judging the lock state of the current object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be the re-lock in the step 4; step 6, under the condition that the lock is judged to be degraded in step 5, the lock state is read again, and the lock state is possibly light lock or no lock; step 7, under the condition that the lock is not degraded in the step 5, adding 1 to the conflict mark of the re-lock; step 9, blocking the first thread under the condition that the re-lock conflict mark is added with 1 in step 7; step 10, the re-lock conflict flag is decremented by 1 on condition that the first thread obtains the lock of the first object. The livelock conflict flag indicates that when a current thread T1 holds the livelock and is ready to be downgraded, if it is found that other threads T2 have entered a code segment protected by a spin lock prior to T1 and are ready to wait for a conflict on the livelock, T2 will set the conflict flag, and no downgrade is detected by T1. In some embodiments, spin lock (spin) protection is added between step 4 and step 5, and spin lock protection is cancelled between step 9 and step 10. The spin lock is added for protection, so that other threads except T2 can not enter the spin lock protected code blocks temporarily, the code blocks comprise two blocks, one is a lock degradation protected code segment, and the other is a code segment in a monitor enter, which is ready to enter conflict waiting.

In a fifth aspect, there is provided a computer program product for, when run on a computer, causing the computer to perform the lock operation method of any of the implementation forms of the first and second aspects.

Drawings

Fig. 1 shows a schematic structural diagram of an electronic device 100 according to an embodiment of the present application.

Fig. 2 shows a software architecture block diagram of the electronic device 100 of an embodiment of the invention.

Fig. 3 illustrates providing a lock structure according to an embodiment of the present application.

Fig. 4 illustrates that embodiments of the present application provide a light lock and heavy lock mechanism.

Fig. 5A to 5F illustrate user experience scenarios.

Fig. 6 illustrates a lock operation method provided in an embodiment of the present application.

Fig. 7 illustrates a lock operation method provided in an embodiment of the present application.

Fig. 8 illustrates a lock operation method provided in an embodiment of the present application.

Fig. 9A and 9B illustrate a lock operation method provided in an embodiment of the present application.

Fig. 10 illustrates a lock operation method provided in an embodiment of the present application.

Fig. 11 illustrates a lock operation method provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Wherein, in the description of the embodiments of the present application, "/" means or is meant unless otherwise indicated, for example, a/B may represent a or B; "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, "plurality" means two or more than two.

Hereinafter, the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first", "a second", etc. may explicitly or implicitly include one or more such feature. In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" is two or more.

To clearly illustrate a Java relock degradation method provided by embodiments of the present application, concepts that may occur in some subsequent embodiments will first be described.

An Operating System (OS), which is system software that manages computer hardware and software resources, provides a common service for computer programs.

Runtime (also known as runtime environment (runtime environment) or runtime system (runtime system) is an environment in which a semi-or fully-compiled runtime code is run on a target machine. The runtime referred to herein is Java runtime.

A process (process), which is a running activity of an application program on a certain data set, is a basic unit of resource allocation and scheduling by an operating system (such as an android system). Each process occupies an address space, and an application program runs on an operating system in the form of one or more processes to realize corresponding functions.

A thread (thread), which is an entity of a process, is a smaller unit of base that can run independently than a process. A thread may share all of the resources owned by a process with other threads that belong to the same process. One thread may create and cancel another thread and multiple threads in the same process may execute concurrently.

Application threads (application thread), which are threads that an application produces on the fly, are suspended on a list (list) by the runtime system after creation.

In the synchronous (synchronized), in the java program running, a mutual exclusion means is adopted for the objects in order to ensure the multi-thread concurrency, so that the same code segment is only run by one thread at the same time, and the running confusion is avoided. The exclusive approach is typically to add synchronized keywords. The synchronized of the Java language level, when executed, translates into a lower level monitor entry (monitor exit) and monitor exit (monitor exit), where monitor entry is placed at the protected code header and monitor exit is placed at the protected code trailer. This means that the thread, in order to run the program with the synchronized key added, must run the monitor entry to enter the object lock and run the monitor exit to exit the object lock. Each livelock (FatLock) will have its own monitor identity, i.e., the aforementioned monitor id. All monitors are placed in the same area of the electronic device software structure, and in some implementations, a java virtual machine for running a java program is provided in the electronic device, so that the monitors can be stored in a specific area of the java virtual machine.

Locks (locks) are a mechanism to ensure that only one thread accesses a method or variable at a time. In the Java language, when a thread accesses an object, a piece of code, the lock to which the object belongs must be acquired, otherwise the thread will wait (or block) until the lock is released and the released lock is successfully acquired. That is, at most only one thread can acquire the lock, and when thread A attempts to acquire the object lock held by thread B, thread A must wait or block until thread B releases the lock before thread A can acquire the lock to access the corresponding code segment.

A light lock (ThinLock) will have its state set from un lock to ThinLock when it is first acquired by a thread after which the lock is not in conflict or will remain in light lock state when the thread has reentrants and its number of reentrants does not exceed the maximum value indicated in the light lock LockWord. When the thread releases this ThinLock, its state will be set to un lock.

A lock (FatLock) is updated from ThinLock to FatLock when the competition is relatively strong (the sched_yield is called for more than a certain number of times when competing threads wait), the thread dead weight times exceeds the maximum value represented by ThinLock, or Java methods such as wait, sleep and the like are called.

Lock degradation (rotation) is the change of a heavy lock to a light lock or no lock. Lock degradation is also referred to herein as downgrade for context expression smoothness.

Blocking (block), which is typically referred to as a scenario when a thread executes a shared code segment, is unable to enter the code segment because one thread takes a lock while other threads are waiting for the lock to be released.

Garbage collection (garbage collection, GC), which is a garbage collection module in operation, is performed on objects not used in the current system, reducing the burden of the system memory. The GC trigger conditions of ART include: the memory allocation fails; explicitly calling a system. Gc () function; clipping (trim) the heap (heap) in run-time, etc.

An Application (APP) is application software that may cause a computing device to perform tasks for a user of the computing device.

system_server: is a process running services in the operating system, is the basic requirement for the provider of basic services and the system to run. System_server is

Other names are possible in other operating systems, but are within the scope of the term system_server in this application if the nature is that the process running the service in the operating system is the provider of the basic service.

The lock operation method provided by the embodiment of the application runs on the electronic equipment. The lock operation device provided by the embodiment of the application is arranged in the electronic equipment. Corresponding to products on the market, the electronic device may correspond to a smart phone, a portable phone, a game machine, a television, a display unit, a head up display unit for a vehicle, a notebook computer, a laptop computer, a tablet Personal Computer (PC), a Personal Media Player (PMP), a Personal Digital Assistant (PDA), a set-top box, and the like. The electronic device may also be implemented as a communication terminal having a communication module, which may communicate with an external electronic device such as a server or the like, or perform operations by interworking with the external electronic device. Any electronic device capable of executing computer instructions may be used to execute the lock operation method and the lock operation device provided in the embodiments of the present application.

In order to facilitate understanding of the application lock operation method and the application lock operation apparatus provided in the embodiments of the present application, first, an exemplary structure of an electronic device and an exemplary structure of a software structure of the electronic device will be briefly described with reference to fig. 1 and 2.

The electronic device 100 may include a processor 110, wherein the processor 110 may include memory therein. The electronic device 100 may also optionally include an internal memory 121, an external memory interface 120, a display 194, a touch sensor 180k, a usb interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, and a SIM card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a Neural network processor (Neural-network Processing Unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interface may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a universal input output (general-purpose input/output (UART)

input/output, GPIO) interfaces, subscriber identity module (subscriber identity module, SIM) interfaces, and/or universal serial bus (universal serial bus, USB) interfaces, etc.

The I2C interface is a bi-directional synchronous serial bus comprising a serial data line (SDA) and a serial clock line (derail clock line, SCL). In some embodiments, the processor 110 may contain multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc., respectively, through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, such that the processor 110 communicates with the touch sensor 180K through an I2C bus interface to implement a touch function of the electronic device 100.

The I2S interface may be used for audio communication. In some embodiments, the processor 110 may contain multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 via an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, to implement a function of answering a call through the bluetooth headset.

PCM interfaces may also be used for audio communication to sample, quantize and encode analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled through a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 through the PCM interface to implement a function of answering a call through the bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus for asynchronous communications. The bus may be a bi-directional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is typically used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through a UART interface, to implement a function of playing music through a bluetooth headset.

The MIPI interface may be used to connect the processor 110 to peripheral devices such as a display 194, a camera 193, and the like. The MIPI interfaces include camera serial interfaces (camera serial interface, CSI), display serial interfaces (display serial interface, DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the photographing functions of electronic device 100. The processor 110 and the display 194 communicate via a DSI interface to implement the display functionality of the electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface may be used to connect a charger to charge the electronic device 100, or may be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, etc.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present invention is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

The charge management module 140 is configured to receive a charge input from a charger.

The wireless communication function of the electronic device 100 may be implemented by the antenna module 1, the antenna module 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc. applied on the electronic device 100.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ an LCD (liquid crystal display ), an OLED (organic light-emitting diode), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N displays, N being a positive integer greater than 1.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121. The memory 121 may include a stored program area and a stored data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The touch sensor 180K, also referred to as a "touch panel". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194.

The keys 190 include a power-on key, a volume key, etc. The keys may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. Embodiments of the invention are configured in a layered manner

The system is an example illustrating the software architecture of the electronic device 100.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, it will

The system is divided into four layers, namely an application program layer, an application program framework layer and a An Zhuoyun line (++)>

runtimes) and system libraries, and kernel layers. An Operating System (OS) of the electronic device 100 includes an application framework layer, an Zhuoyun rows and a system library.

The application layer may include a series of application packages.

As shown in fig. 2, the application package may include applications for cameras, gallery, calendar, phone calls, maps, navigation, WLAN, bluetooth, music, video, short messages, etc.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 2, the application framework layer may include a window manager, a content provider, a view system, a telephony manager, a resource manager, a notification manager, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The telephony manager is used to provide the communication functions of the electronic device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the electronic device vibrates, and an indicator light blinks, etc.

Run time includes a core library and virtual machines. />

runtime is responsible for scheduling and management of the android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio video encoding formats, such as: MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

Fig. 3 shows a lock structure provided by an embodiment of the present application. A java object may include multiple regions, including for example, an object Header (Header) and Instance Data (Instance Data). Header typically includes the runtime data of the object itself, such as hash codes and UnLock, thinLock, fatLock classifications. In this embodiment, 32 bits (bits) are reserved in the Header as a lock word (lockword) area. However, the region of the lockword is not exclusive, and other information such as a hash code may be stored, so that the status bit of the lockword should be checked first when the lockword information is read and used. In other embodiments, the region of the lockword may be set to exclusive, so that the lockword need not be read again to query whether the content therein is a lock or not.

The types of locks include lock-less (UnLock, also written UnLock, etc., case-indistinguishable), light lock (ThinLock, also written thinLock, case-indistinguishable), and heavy lock (faslock, also written FatLock, case-indistinguishable). The type is embodied by the structure of the lockword.

As shown in FIG. 3, in a lock-free, the first row is any 32bit lockword, where the first two bits from left represent the lock status. The second row is in the lock-free state. It can be seen that in a lock-free state, represented by 00, the remaining bits are all 0, and in the figure the sum of the remaining bits is written to be 0 for simplicity, representing that the remaining bits are all 0.

In a light lock, the first row is any 32bit lockword, where the first two bits from left represent the lock status. The second row is the state of the light lock. It can be seen that in a light lock, the lock state is indicated by 00, and the next two bits are free, reserved bits, and in other embodiments may be used for hash flags, etc. The remaining bits are divided into a number of reentrant times (lock count) and a thread identification (thread id). The number of reentrants represents the number of times a particular thread continues to enter a lock without releasing the lock. The thread identification records the thread ID currently holding the light lock. In this embodiment, 12 bits are divided for the reentrant times and 16 bits are identified for the thread. In other embodiments, the number of re-entrants may be given by other numbers of digits.

In a relock, the first row is any 32bit lockword, where the first two bits from left represent the lock state. The second row is the state of the lock again. It can be seen that in a relock, the lock state is denoted by 01, the next two bits are free, reserved bits, and in other embodiments may be used for hash flags, etc. The remaining bits are assigned to the monitor id (monitor id). Each FatLock has its own monitor.

Fig. 4 illustrates that embodiments of the present application provide a light lock and heavy lock mechanism. An object's lock cannot be held by more than one thread at the same time, i.e., after one thread takes the object's lock, the other threads cannot acquire the lock before it releases the lock. As shown in fig. 4, how T2 waits for a lock is explained according to whether the current state of the lock held by T1 is a light lock or a heavy lock.

a) The state of the lock being a light lock

When one thread T2 is blocked on the lock, T2 can give out the ownership of the CPU by calling the sched_yield, the system can add the thread to the tail of the queue, if no thread with higher priority than the thread is available, the thread immediately resumes execution, otherwise, the other threads are allowed to occupy the CPU for further execution, the lock state is detected when the CPU is obtained again by T2, if the lock is released by T1, the lock is obtained by T2, only context switching is involved at the moment, the cost is small, context switching refers to the state of a storage register, a signal and the like when the state is dequeued, and the purpose is to normally execute a flow when the state is switched back. In this embodiment the accounting number is the number of times sched_yields are called by T2 during the time T1 holds a light lock, if a certain threshold is exceeded, for example 50 times, indicating that the lock causes a severe contention (content) and thus causes T2 to change the light lock to a heavy lock, but the holder of the heavy lock is also T1.

b) The state of the lock being a lock again

If the lock is a re-lock, the kernel enters and sleeps through a futex system call when the T2 accesses the lock, the kernel executes a complex scheduling algorithm, and wakes up the blocked thread T2 through the futex system call when the T1 releases the lock. The whole process not only has context switching, but also involves expensive overheads such as thread state change, kernel scheduling and the like. In addition, for FatLock, there is overhead in its operation of generating and destroying Monitor.

If the generated heavy lock can be degraded into a light lock or a lock-free lock under the condition of little competition, the system overhead can be saved, the execution speed of the protected code segment is increased, and the use smoothness of the electronic equipment is further improved. One known approach is to uniformly downgrade the locks when allocating Memory (allocatememory), GC. Trim (trim) is made to memory, for example, when allocating memory, GC, and includes relock demotion. All threads created by the application are suspended before the execution lock is demoted, and execution of the threads created by the application is resumed after the demotion. This strategy is easy to implement, but has the disadvantage of requiring to do while suspending the threads created by the application in the running virtual machine, increasing the dwell time and disrupting the user experience if a large number of relocks are accumulated at this time that need to be downgraded. And the time at which GC occurs is difficult to predict, and thus it is difficult to alert the user that jamming is imminent before GC occurs. As shown in fig. 5A to 5E, a bad experience for the user may be caused by a pause in GC. For example, as shown in fig. 5A, a user is using an electronic device to make a call to a call object with a high social status. After the call is ended, the user clicks on the hook as shown in fig. 5B. The user then places the phone in a pocket as shown in fig. 5C. The user succeeds in hanging up and then expresses emotion in a drastic language as shown in fig. 5D. However, while the on-hook GC occurs, all threads created by the application, including the conversation application thread, are suspended and the on-hook operation is not performed, as shown in fig. 5E. After the user is put in the pocket, the GC is finished, and the call application thread is restored, so that the intense language expression of the user is collected by the electronic equipment and heard by a call object, and poor use experience of the electronic equipment is generated after the user finds. From this case, it can be seen that if time can be reduced by centralizing lock degradation without GC, it can help avoid the user's bad experience with the electronic device. The extension of the centralized lock downgrade to the GC depends on how many locks are accumulated at the GC, and if there are many threads running before the GC, for example, during the power-on process, the lock downgrade takes longer. The delay of lock degradation to the GC may be up to about 200 ms.

Fig. 6 illustrates a lock operation method provided in an embodiment of the present application. In the electronic device an object a is arranged, for example a piece of code, the thread T1 created by the application program is holding a lock of the object a. The lock of an object may hereinafter be simply referred to as an object lock for clarity of presentation. As mentioned above, the program in java language may, in operation, modify an object with a synchronized key for mutual exclusion, for example in the form of synchronized (obj), where obj represents the object. For synchronized syntax, a Java Compiler (Java Compiler) inserts SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other running mechanism similar to the java virtual machine that converts the java language into a language understandable to the operating system would be implemented as a bottom layer for SyncEnter and SyncExit instructions with corresponding monitor enter and monitor exit like functions. The thread will enter the monitor exit module when the lock is released. The lock operation method provided in this embodiment runs in the MonitorExit module. It is not necessary to suspend all threads created by an application program as in GC in the course of executing the lock operation method provided in the present embodiment.

Without suspending all threads created by the application, in step 601, the type of lock is checked, if it is determined to be a heavy lock, step 602 is performed, where it is determined that the Object (Object) corresponding to the current lock is not used for Java methods of wait, sleep, etc., nor is in conflict (i.e., other threads are ready to block on the lock), then the lock is downgraded in step 603.

In step 601, the current state of the object lock may be determined by the structure of the lockword. A lockword is determined to be a lock if it has the structure as in the lock (Fatlock) of fig. 3, i.e., the lock head two bits are 01 and the last 28 bits are monitor id.

In step 603, the lock downgrades. Lock downgrading includes downgrading to light locks and no locks.

Fig. 7 illustrates a lock operation method provided in an embodiment of the present application. An object a, for example a piece of code, is arranged in the electronic device, a thread T1 created by the application program is holding a lock of the object a, and the state of the lock is a re-lock. T2 accesses the object and then enters the monitor Enter module where the lock operation method provided by this embodiment runs. In step 701, it is determined that the lock state of the current object is locked again. The specific measure is that the lockword is read, whether the lockword is a relock is judged by the two-bit marks of the lockword head and the structure, which means that whether the lockword is a relock is judged firstly, and the program behind the last colon is allowed to be executed under the condition that the lockword is a relock. In step 702, spin lock (spin) is applied to protect such that threads other than T2 are temporarily unable to reenter the spin lock protected code block, which includes two blocks, one being the lock downgraded protected code segment and one being the code segment in the monitor enter ready to enter conflict waiting. In step 703, the lock state is checked again, for example, by checking lockword through the lw. Getstate () function to learn the lock state.

If the lock has been downgraded as a result of the check in step 703, the spin lock is cancelled in step 704 and the lock state is re-read in step 705, here either UnLock or ThinLock.

If the lock is not downgraded as a result of the check in step 703, the livelock conflict flag is incremented by 1 in step 706. The reslock conflict flag indicates that when the current thread T1 holds the reslock and is ready to be downgraded, if other threads T2 are found to enter a code segment protected by the spin lock in the monitor before T1 and are ready to wait for conflict on the reslock at this time, the conflict flag is set by T2, and the downgrade is not carried out when the T1 is detected. The spin lock is unprotected in step 707. T2 enters the blocking state in step 708. Until T2 takes the object lock, it will not decrement the livelock conflict flag by 1 in step 709.

In this embodiment, the step 702 of adding spin lock protection, and the steps 704 and 707 of canceling spin lock protection are optional.

Example codes for this embodiment are:

fig. 8 illustrates a lock operation method provided in an embodiment of the present application. The lock operation method of fig. 8 and the lock operation method of fig. 7 act on the same object a. The lock operation method of fig. 8 runs in the MonitorExit module. Thread T1 then goes to the MonitorExit module when the lock is released. In step 801, T1 checks if there are other threads waiting for the object lock. For example, checking whether there is a thread that invokes a wait, sleep, etc. java function for a lived re-lock of T1, and no re-lock conflict flag. If not, go to step 802. In other embodiments, it is also checked in step 801 whether the lockword of the current object lock is written as a hash code. If there is no hash code nor waiting thread, step 802 is entered. In step 802, spin lock protection is added so that no other thread can execute the code segment protected by the spin lock while T1 performs the next step in the present lock operation method. In step 803, it is checked whether the livelock conflict flag is 0. A value of 0 means that no other thread entered the monitor enter module of the current object and was ready to block waiting when T1 was ready to release the lock. A value other than 0 means that there are other threads that were downgraded into the monitor enter before T1 and are ready to block waiting on the lock. If the result of the check in step 803 is that the livelock conflict flag is not 0, then the spin lock protection is canceled in step 804, the lock operation method flow in this embodiment results. I.e. the relock is not downgraded. If the result of the check in step 803 is a livelock conflict flag of 0, then in step 805 the livelock is downgraded to no lock. The method is, for example, to zero the lockword. And the spin lock is revoked in step 806. In this embodiment, the step 802 of adding spin locks and the steps 804 and 806 of cancelling spin locks are optional. Exemplary codes for this embodiment are:

Fig. 9A and 9B illustrate a lock operation method provided in an embodiment of the present application. The lock operation method of fig. 9A and 9B and the lock operation method of fig. 7 act on the same object a. The lock operation method of fig. 9A and 9B runs in the MonitorExit module. Thread T1 runs object A's code to release the lock and then walks to the MonitorExit module. Looking first at FIG. 9A, in step 901, it is checked whether the holder identification of the current object lock is the thread running the lock operation method. If the holder identification of the current object lock is not the thread running the lock operation method, the description is in error, and the flow of the method is ended through a return function. If the holder identification of the current object lock is the thread running the lock operation method, it is checked in step 902 if the number of reentrants is 0. The number of reentrants records the total number of times thread T1 entered the monitor enter module of the current object without releasing the lock. The general rule of operation of the lock mechanism in Java programs is that every time a monitor exit is taken, the number of reentrants is reduced by 1, and until it is reduced to 0, the thread holding the lock is not allowed to release the lock. If the number of re-entrants is checked to be 0 in step 902, the lock holder identification is zeroed in step 903. In optional step 904 it is checked whether there is a thread waiting for the current object lock and at least one of the waiting threads is awakened in the condition that there is a thread waiting. If it is checked in step 902 that the number of re-entrants is not 0, the number of re-entrants is decremented by 1 in step 905. After step 904 or step 905, go to step 906 where a determination is made in step 906 as to whether any threads have blocked or invoked wait on the lock, sleep Java methods. If so, ending the flow of the lock operation method, namely ending the lock operation method without degrading the re-lock. Fig. 9B shows step 907 and subsequent steps. In step 907, it is determined whether the lock holder identification is 0. If it is determined in step 907 that the lock holder identification is not 0, spin lock protection is applied in step 908. In step 909, the heavy lock is downgraded to a light lock on condition that the heavy lock conflict flag is 0. The spin lock is unprotected in step 910. If it is determined in step 907 that the lock holder identification is 0, spin lock protection is applied in step 911. In step 912, the livelock is downgraded to no lock on condition that the livelock conflict flag is 0. The spin lock is unprotected in step 913. The flow of the lock operation method ends after step 910 or step 913. Steps 908 and 911 of adding spin lock and steps 910 and 913 of cancelling spin lock are optional. Example code for the lock operation method in this embodiment is:

/>

The lock operation method provided by the embodiments of fig. 6, 8 and 9A-B enables the non-competing locks to be dynamically downgraded in the process of running codes on threads, and the time of each downgrade is in millisecond level, so that the large time of downgrade of the centralized lock is dispersed along with the action of the threads, and the blocking of the electronic equipment is not caused, thereby maintaining the smooth use experience of users. For example, an electronic device running the lock operation method provided in the embodiment of the present application is compared with an electronic device running the google art system without the lock operation method. After the object obj is modified by using the synchronized key, the compiler inserts the SyncEnter and SyncExit into the code head and tail of the object, and the SyncEnter and SyncExit are implemented by corresponding to the underlying MonitorExit function and MonitorExit function, respectively. As shown in the following code:

original Java code:

statement1; i/statement 1

Modification of object obj with synchronized (obj) {// synchronized keywords

CodeSquence; sequence of/(and/or code)

}

State 2; i/statement 2

The compiled synchronized becomes calls to MonitorEnter and MonitorExit:

Statement1；

MonitorEnter(obj){

CodeSquence；

}

MonitorExit(obj)

Statement2；

the execution time of a thread from state 1 to state 2 depends on the execution time of the lock and the execution time of the code sequence protected by the lock. In comparing the performance of electronic devices with and without the lock operation method provided by the embodiments of the present application, the number of lock degradation and the number of re-locks are mainly compared, and the execution time is not mainly compared, because differences in code sequence execution time may be caused by compiler differences, system differences, and the like.

The test is started from Zygote, systemServer to 15 seconds, 45 seconds and accumulated for 5 minutes at the start-up, and the light lock, the heavy lock and the lock degradation times are compared for the electronic device X running the original Art and the electronic device Y running the lock operation method provided by the embodiment of the application respectively:

1) 15 seconds:

electronic equipment	Number of light locks	Quantity of locks	Number of relock downgrades
				X	574224	231660	0
Y	700025	15699	2183

2) 45 seconds:

electronic equipment	Number of light locks	Quantity of locks	Number of relock downgrades
				X	691128	285566	0
Y	870103	18499	2850

3) Cumulative 5 minutes:

from the test results the following conclusions can be drawn:

1) The electronic device Y dynamic lock degradation can timely release the system pressure, the degradation times are more than 3000, and the electronic device X does not execute lock degradation, so that the system pressure cannot be released from the lock again. The number of the re-locking generated by the electronic equipment Y is reduced by more than hundred thousand times compared with the number of the re-locking generated by the electronic equipment X, so that a large amount of system overhead is reduced;

2) From the data of five minutes, the total number of the light locks and the heavy locks of the electronic equipment X is about one hundred thousand, the total number of the light locks and the heavy locks of the electronic equipment Y is about one hundred zero sixty thousand, and the total number is almost equal, which indicates that the number of the lock objects is equal. One hundred and forty thousands of locks of the electronic device Y are light locks, and only less than two ten thousands are heavy locks. Nearly eighty of the total number of locks of electronic device X are light locks and thirty-two thousand are heavy locks. The lock operation method provided by the embodiment of the application can degrade the heavy lock in time and relieve the system pressure;

3) Centralized degradation in electronic device X, such as occurs over a period of five minutes or less, may involve pausing, resuming operation, and may result in significant jamming.

When one thread enters the monitor enter for the first time before the other threads, a lock is obtained, and the lock is changed from an initial state (UnLock) to ThinLock;

when this thread entry reenters, lockcount++; if LockCount has exceeded the maximum value that can be represented at this time, then upgrade this lock from ThinLock to FatLock,

if other threads enter and the lock state is ThinLock at the moment, the thread sched_yield waits for a certain number of times; if the number of times is waited for to exceed a certain number of times, upgrading the lock from ThinLock to FatLock;

if the hash code is the hash code, upgrading or saving a hash mark (HashFlag);

in a MonitorEnter FatLock scene, under the protection of spinLock, reading LockWord again and detecting the state, if no other Thread Deflate exists at this time, setting a content Flag, and executing a normal Lock flow; the lock function is to either take the lock or wait. If the state is already changed by other Thread deflates, the UnLock or ThinLock state is walked again; and exiting the SpinLock protection.

When the thread enters and the lock is in a UnLock state, an error is generated, and an exception is thrown;

when the thread enters and the lock is in the ThinLock state, lockCount-, if LockCount is already 0, the lock is set in the Unlock state;

when the thread enters and the lock is the hash code, upgrading or saving the hash code;

in a MonitorExit- > Unlock FatLock scene; detecting that the current lock Wait Number is empty, namely, no thread for Java methods such as Wait and sleep exists, and no thread is in conflict; counting the Number of the Deflag if a certain Number of times is reached; under the protection of spinLock, detecting whether other Thread exists before the current Thread default scene; if not, performing FatLock to UnLock or ThinLock conversion, and finishing degradation (Deflate); and exiting the SpinLock protection.

The embodiment of the application also provides an electronic device, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, and is characterized in that the electronic device is enabled to realize the lock operation method provided by any embodiment of the application when the processor executes the computer program.

Embodiments of the present application also provide a computer storage medium comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform the lock operation method provided by any of the embodiments of the present application.

Embodiments of the present application also provide a computer program product which, when run on a computer, causes the computer to perform the lock operation method provided by any of the embodiments of the present application.

In the above embodiments, the implementation may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product may include one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, fiber optic, digital Subscriber (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means from one website, computer, server, or data center. The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic Disk), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A lock operation method running on an electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, the first thread holding a lock of the first object, the lock including a lock word that records a state of the lock, the lock operation method comprising performing without suspending the first thread: step 1, checking the state of a lock of the first object; step 2, judging whether other threads wait for the lock of the first object under the condition that the lock of the first object is a reslock; and 3, judging in the step 2 that no other thread demotes the lock of the first object under the condition of waiting for the lock of the first object.

2. The lock operation method of claim 1, wherein demoting the lock of the first object comprises converting the lock of the first object to a light lock and to no lock.

3. The lock operation method according to any one of claims 1 to 2, wherein the step 1, the step 2 and the step 3 are performed in a MonitorExit module.

4. The lock operation method according to claim 1, wherein the condition that no other thread waits for the lock of the first object is determined in the step 3 that no other thread has been blocked on the lock of the first object or invoked a java method wait or sleep.

5. The lock operation method according to claim 1, further comprising executing in a monitor enter module: step 4, judging the state of the lock of the first object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be a re-lock in the step 4; step 6, under the condition that the lock is degraded to be lock-free in the step 5, enabling the first thread to walk a lock-free flow for the first object; step 7, adding 1 to the conflict sign of the re-lock under the condition that the lock is not degraded to be lock-free in the step 5; step 8, blocking the first thread under the condition that the re-lock conflict flag is increased by 1 in the step 7; and step 9, subtracting 1 from the re-lock conflict mark under the condition that the first thread obtains the lock of the first object.

6. The lock operation method according to claim 1, characterized in that the lock operation method further comprises: in the step 2, it is also checked whether the lock word of the first object lock is a hash code; in the step 3, if it is determined in the step 2 that no other thread waits for the lock of the first object and the lock word is not a hash code, checking whether the re-lock conflict flag is 0, and if it is 0, degrading the lock of the first object to no lock.

7. A lock operation method running on an electronic device, the electronic device having disposed thereon a first object, the first object being a piece of code, the electronic device having disposed thereon at least one application, the at least one application having a first thread, the first thread holding a lock of the first object, the lock including a lock word that records a state of the lock, the lock operation method comprising performing without suspending the first thread: step 1, checking whether the reentry times is 0; step 2, under the condition that the reentry time is 0 in the step 1, the lock of the first object is downgraded to be lock-free under the condition that a reentry conflict mark is 0; and 3, under the condition that the reentrant times are not 0 in the step 1, degrading the lock of the first object to be a light lock under the condition that the reentry conflict mark is 0.

8. The lock operation method of claim 7, wherein demoting the lock of the first object comprises converting the lock of the first object to a light lock and to no lock.

9. The lock operation method according to any one of claims 7 to 8, wherein the step 1, the step 2 and the step 3 are performed in a MonitorExit module.

10. The lock operation method according to any one of claims 7 to 8, further comprising executing in a monitor enter module: step 4, judging the state of the lock of the first object; step 5, checking the state of the lock under the condition that the state of the lock is judged to be a re-lock in the step 4; step 6, under the condition that the lock is judged to have been degraded in the step 5, the lock state is regained; step 7, adding 1 to the conflict sign of the re-lock under the condition that the lock is not degraded in the step 5; step 8, blocking the first thread under the condition that the re-lock conflict flag is added with 1 in step 7; and step 9, subtracting 1 from the re-lock conflict mark under the condition that the first thread obtains the lock of the first object.

11. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the computer program, causes the electronic device to implement the lock operation method according to any one of claims 1 to 10.

12. A computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the lock operation method according to any one of claims 1 to 10.