CN111459462A

CN111459462A - Decentralized relock demotion

Info

Publication number: CN111459462A
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: 2020-07-28
Anticipated expiration: 2039-01-20
Also published as: WO2020147859A1; CN111459462B

Abstract

An embodiment of the present application provides a lock operation method, where the lock operation method is executed on an electronic device, where a first object is arranged on the electronic device, where the first object is a piece of code, where at least one application program is arranged on the electronic device, where the at least one application program has a first thread, where the first thread holds a lock of the first object, where the lock includes a lock word that records a state of the lock, and the lock operation method includes performing, without pausing the first thread: step 1, checking the state of a lock of a first object; step 2, under the condition that the lock of the first object is relocked, judging whether other threads wait for the lock of the first object; and 3, degrading the lock of the first object under the condition that no other thread waits for the lock of the first object in the step 2.

Description

Decentralized relock demotion

Technical Field

The present invention relates to the field of computers, and in particular, to a lock operation method and an electronic device operating the lock operation method.

Background

Java language is widely used, for example, in web services using J2EE, in an android (android) operating system generally used in mobile terminals, in application software that can run on an android operating system or an ios operating system, in rich client applications (rich client applications), and the like, the Java language can be developed, so that the software runs in a Java running environment.

One feature of Java is to support parallel execution (also called concurrency), i.e. there are multiple programs or multiple threads simultaneously in a period, and some of them may need to access the same resource, e.g. the same object, thereby creating competition. To ensure orderly execution, Java provides an object-based lock (lock) mechanism, where only one thread can hold a lock at a time, and only after the thread releases the lock, other threads may re-hold the lock of the object and execute the program code contained in the object. One of the locks used in the more competitive case is called a heavy lock (fallock), which results in more system calls and thus a larger overhead. And once the object has a relock, it is not cancelled by the thread taking (object) lock and releasing (release) lock. In other words, without special intervention, these objects will always piggyback a relock, with the accompanying system calls placing a greater burden on the system as the number of relocked objects increases and the number of times they are accessed during their lifecycle accumulates. Some of the objects may no longer be in a race condition after having a relock, for which a relock is no longer necessary. It can be seen that a lock destaging mechanism is needed to destage unnecessary relocks to reduce system load and improve operating efficiency.

Currently, the art (android runtime) virtual machine developed by google provides a lock downgrading mechanism attached to Garbage Collection (GC). GC pauses the operation, i.e., the thread created by the application is paused. On one hand, the centralized lock degradation mode during GC cannot solve the problem of unnecessary system burden caused by relocking between two GC processes, and on the other hand, pause of threads during GC processes brings pause experience to users (according to different GC cleaning ranges, the time consumed by a single GC process can reach hundreds of milliseconds). Pausing a virtual machine is therefore undesirable from the perspective of ensuring a smooth user experience, while a GC that is too long-spaced is inefficient from a lock degradation perspective.

Disclosure of Invention

The embodiment of the present application provides a distributed lock downgrading mechanism, where the lock downgrading time is independent of the GC, and when the current lock holding thread releases the relock, if it is detected that the lock is no longer in contention, the relock is downgraded in time. One lock degradation takes nanoseconds and is imperceptible to the user. Therefore, the distributed lock degradation mechanism ensures that the fluency experience of a user is not influenced by lock degradation on one hand, and avoids unnecessary relocking overhead on the other hand in time.

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

in a first aspect, a lock operation method is provided, where the lock operation method is executed on an electronic device, where a first object is arranged on the electronic device, where the first object is a piece of code, where at least one application program is arranged on the electronic device, where the at least one application program has a first thread, where the first thread holds a lock of the first object, where the lock includes a lock word (lockword) that records a state of the lock, and the lock operation method includes performing, without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, under the condition that the lock of the first object is relocked, judging whether other threads wait for the lock of the first object; and 3, degrading the lock of the first object under the condition that no other thread waits for the lock of the first object in the step 2. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the java compiler (javaccompiler) will insert SyncEnter and SyncExit instructions at the beginning and end of its protected code fragment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread releases the lock within the MonitorExit module before exiting the protected code segment. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. 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 to no lock.

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

In some embodiments, the condition that no other thread waits for the lock of the first object in step 3 is that no Java Method for wait, sleep, etc. is available, and that no other thread is in a conflict state, where the conflict state indicates that another thread is ready to block on the lock.

In some embodiments, the lock operation method further comprises executing in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded to be lock-free in the step 5, the first thread reads the lock state again aiming at the lock of the first object and walks the corresponding lock-free flow; step 7, adding 1 to the relocking conflict mark under the condition that the lock is not degraded to be lock-free in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object lock should take when its state is lock-free. Typically a thread gets a lock and changes no lock to a light lock by putting its own identity into the lock word (lockword). The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the spin-locked code segment before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and T1 detects that no demotion is done. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The effect of the spin lock protection is to make other threads than T2 temporarily unable to enter the spin lock protected code block, which includes two code segments, one code segment for lock degradation protection and one code segment for the monitor enter ready to enter conflict wait.

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

In a second aspect, a lock operation method is provided, where the lock operation method is executed on an electronic device, where a first object is arranged on the electronic device, where the first object is a piece of code, where at least one application is arranged on the electronic device, where the at least one application has a first thread, where the first thread holds a lock of the first object, where the lock includes a lock word (lockword) that records a state of the lock, and where the lock operation method includes performing, without suspending the first thread: step 1, checking whether the number of reentry times is 0; step 2, under the condition that the number of reentries is judged to be 0 in the step 1, the first object lock is degraded to be lock-free under the condition that the re-locking conflict mark is 0; and 3, degrading the first object lock into a light lock under the condition that the number of times of reentry is not 0 and the heavy lock conflict mark is 0 in the step 1. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module before it runs the code and releases the lock. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. The lock states include heavy lock, light lock, and no lock. The number of reentries records the total number of times the thread T1 entered the MonitorEnter module for the object without releasing the current object lock.

In some embodiments, the lock operation method further comprises executing in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded in the step 5, the lock state is obtained again, and the lock state may be no lock or light lock; step 7, adding 1 to the relock conflict mark under the condition that the lock is judged not to be degraded in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the spin-locked code segment before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and T1 detects that no demotion is done. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The effect of the spin lock protection is to make other threads than T2 temporarily unable to enter the spin lock protected code block, which includes two code segments, one code segment for lock degradation protection and one code segment for the monitor enter ready to enter conflict wait.

In a third aspect, an electronic device is provided, which comprises a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to make the electronic device implement the lock operation method of any implementation form of the first aspect and the second aspect of the present application.

In some embodiments, an electronic device implements a lock operation method, the lock operation method running on the electronic device, a first object is arranged on the electronic device, the first object is a piece of code, at least one application program is arranged on the electronic device, the at least one application program has a first thread, the first thread holds a lock of the first object, the lock includes a lock word (lockword) recording a state of the lock, and the lock operation method includes executing without suspending the first thread: step 1, checking the state of a lock of a first object; step 2, under the condition that the lock of the first object is relocked, judging whether other threads wait for the lock of the first object; and 3, degrading the lock of the first object under the condition that no other thread waits for the lock of the first object in the step 2. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert the SyncEnter and syncexit instructions at the beginning and end of its protected code fragment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module before it runs the code and releases the lock. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. The lock states include heavy lock, light lock, and no lock.

In some implementations, in a lock operation method implemented by an electronic device, 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 method of lock operation implemented by the electronic device, steps 1, 2 and 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 no Java Method such as wait, sleep, or the like is used, and the lock is not in a conflict state, where the conflict state refers to that the other thread is ready to block on the lock.

In some embodiments, the method of operating a lock implemented in an electronic device further comprises executing in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded to be lock-free in the step 5, enabling the first thread to go through a lock-free flow aiming at the lock of the first object; step 7, adding 1 to the relocking conflict mark under the condition that the lock is not degraded to be lock-free in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object lock should take when its state is lock-free. Typically a thread gets a lock and changes no lock to a light lock by putting its own identity into the lock word (lockword). The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the spin-locked code segment before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and T1 detects that no demotion is done. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The spin lock protection function is to make other threads except T2 temporarily unable to enter the spin lock protected code block, and the code block comprises two code segments, one code segment for lock degradation protection and one code segment for Monitor enter ready to enter conflict waiting.

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

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

the electronic equipment realizes a lock operation method, the lock operation method is operated on the electronic equipment, a first object is arranged on the electronic equipment, the first object is a piece of code, at least one application program is arranged on the electronic equipment, the at least one application program is provided with a first thread, the first thread holds a lock of the first object, the lock comprises a lock word (lockword) for recording the state of the lock, and the lock operation method comprises the following steps of executing the following steps without pausing the first thread: step 1, checking whether the number of reentry times is 0; step 2, under the condition that the number of reentries is judged to be 0 in the step 1, the first object lock is degraded to be lock-free under the condition that the re-locking conflict mark is 0; and 3, degrading the first object lock into a light lock under the condition that the number of times of reentry is not 0 and the heavy lock conflict mark is 0 in the step 1. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module before it runs the code and releases the lock. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. The lock states include heavy lock, light lock, and no lock. The number of reentries records the total number of times the thread T1 entered the MonitorEnter module for the object without releasing the current object lock.

In some embodiments, the method of operating a lock implemented in an electronic device further comprises executing in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded in the step 5, the lock state is read again, and the lock state may be a light lock or no lock; step 7, adding 1 to the relock conflict mark under the condition that the lock is judged not to be degraded in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the spin-locked code segment before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and T1 detects that no demotion is done. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The spin lock protection function is to make other threads except T2 temporarily unable to enter the spin lock protected code block, and the code block comprises two code segments, one code segment for lock degradation protection and one code segment for Monitor enter ready to enter conflict waiting.

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

In some embodiments, an electronic device executes a lock operation method, the lock operation method being executed on the electronic device, a first object being disposed on the electronic device, the first object being a piece of code, at least one application being disposed on the electronic device, 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 (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, under the condition that the lock of the first object is relocked, judging whether other threads wait for the lock of the first object; and 3, degrading the lock of the first object under the condition that no other thread waits for the lock of the first object in the step 2. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert the SyncEnter and syncexit instructions at the beginning and end of its protected code fragment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module before it runs the code and releases the lock. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. The lock states include heavy lock, light lock, and no lock.

In some implementations, in a method of lock operations performed by an electronic device, 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 performed 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 executed by the electronic device, the condition that no other thread waits for the lock of the first object in step 3 is that no Java Method such as wait, sleep, or the like is used, and the lock is not in a conflict state, where the conflict state refers to that the other thread is ready to block on the lock.

In some embodiments, the method for operating a lock performed by an electronic device further includes performing, in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded to be lock-free in the step 5, enabling the first thread to go through a lock-free flow aiming at the lock of the first object; step 7, adding 1 to the relocking conflict mark under the condition that the lock is not degraded to be lock-free in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. A lock-free flow refers to a flow that a thread accessing an object lock should take when its state is lock-free. Typically a thread gets a lock and changes no lock to a light lock by putting its own identity into the lock word (lockword). The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be degraded, if it is found that another thread T2 enters the spin-lock protected code segment before T1 and is ready to be overloaded for waiting on the relock, T2 sets the conflict flag, and T1 detects that no degradation is performed. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The spin lock protection function is to make other threads except T2 temporarily unable to enter the spin lock protected code block, and the code block comprises two code segments, one code segment for lock degradation protection and one code segment for Monitor enter ready to enter conflict waiting.

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

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

an electronic device executes a lock operation method, the lock operation method being executed on the electronic device, a first object being arranged on the electronic device, the first object being a piece of code, at least one application being arranged on the electronic device, 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 (lockword) that records a state of the lock, the lock operation method including performing, without suspending the first thread: step 1, checking whether the number of reentry times is 0; step 2, under the condition that the number of reentries is judged to be 0 in the step 1, the first object lock is degraded to be lock-free under the condition that the re-locking conflict mark is 0; and 3, degrading the first object lock into a light lock under the condition that the number of times of reentry is not 0 and the heavy lock conflict mark is 0 in the step 1. In operation, the java language program may modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module before it runs the code and releases the lock. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC. The lock states include heavy lock, light lock, and no lock. The number of reentries records the total number of times the thread T1 entered the MonitorEnter module for the object without releasing the current object lock.

In some embodiments, the method for operating a lock performed by an electronic device further includes performing, in the MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded in the step 5, the lock state is read again, and the lock state may be a light lock or no lock; step 7, adding 1 to the relock conflict mark under the condition that the lock is judged not to be degraded in the step 5; step 9, blocking the first thread under the condition that the relocking conflict mark is added with 1 in the step 7; and 10, subtracting 1 from the relocking conflict mark under the condition that the first thread acquires the lock of the first object. The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the spin-locked code segment before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and T1 detects that no demotion is done. In some embodiments, a spin lock (spinlock) protection is applied between step 4 and step 5, and a spin lock protection is removed between step 9 and step 10. The effect of the spin lock protection is to make other threads than T2 temporarily unable to enter the spin lock protected code block, which includes two code segments, one code segment for lock degradation protection and one code segment for the monitor enter ready to enter conflict wait.

In a fifth aspect, a computer program product is provided, which, when run on a computer, causes the computer to perform the method of lock operation 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 provided in an embodiment of the present application.

Fig. 2 shows a block diagram of the software structure of the electronic device 100 according to the embodiment of the present invention.

Fig. 3 illustrates a lock structure provided by an embodiment of the present application.

FIG. 4 illustrates an embodiment of the present application providing a light lock and a heavy lock mechanism.

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

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

Fig. 7 illustrates a method for operating a lock according to an embodiment of the present application.

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

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

Fig. 10 illustrates a method for operating a lock provided by an embodiment of the present application.

Fig. 11 illustrates a lock operation method provided by 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. In the description of the embodiments herein, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality" means two or more than two.

In the following, the terms "first", "second", etc. 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 defined as "first," "second," etc. may explicitly or implicitly include one or more of that feature. In the description of the embodiments of the present application, "a plurality" means two or more unless otherwise specified.

For clarity of explanation of the Java relock downgrading method provided in the embodiments of the present application, some concepts that may appear in subsequent embodiments will be introduced first.

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

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

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

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

Application threads (application threads), which are threads that are generated by an application during runtime, are hung on a list (list) by the runtime system after creation.

Synchronization (synchronized), in Java program execution, in order to guarantee multi-thread concurrency, the objects are mutually exclusive, so that the same code segment is executed by only one thread at the same time, so as to avoid execution confusion, the mutually exclusive means is usually to add a synchronized keyword, when executed, synchronized at Java language level will be converted into a lower level monitor entry (monitor entry) and a monitor exit (monitor exit), wherein the monitor entry is arranged at the head of the protected code, and the monitor exit is arranged at the tail of the protected code, which means that a thread wants to execute the program added with the synchronized keyword, it must run the monitor entry to enter the object lock and run the monitor exit to exit the object lock, each relock (Fat L ock) has its own monitor identification, i.e. all the monitors mentioned above are put in the same area of the software structure of the electronic device, in some implementation forms, a virtual area for Java program to run is provided, and a virtual area for Java virtual machine to be stored in can be provided.

Lock (lock) is a mechanism that ensures 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, it must acquire the lock to which the object belongs, 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 obtain the lock, and when thread A attempts to obtain the object lock held by thread B, thread A must wait or block until thread B releases the lock before thread A can obtain the lock to access the corresponding code segment.

A light lock (Thin L ock) whose state is set by Un L ock to Thin L ock the first time it is acquired, and thereafter remains in the light lock state when the lock has been in heavy entry and the number of times it has not exceeded the maximum value indicated in light lock L ockWord, and whose state is set to Un L ock when the thread releases the Thin L ock.

And a heavy lock (Fat L ock), which is upgraded from Fat L ock to Fat L ock when the competition is severe (the competition thread waits for calling the scheduled _ yield more than a certain number of times), the thread self-reentry number of times exceeds the maximum value represented by the Fat L ock, or Java methods such as wait, sleep and the like are called.

Lock destaging (destaging) is the changing of heavy locks to light or no locks. Lock degradation is also referred to herein as degradation for the sake of context smoothness.

Block, generally refers to a scenario where a thread cannot enter a shared code segment while executing the code segment, because the lock is taken by another thread, and the other thread waits for the lock to be released.

Garbage Collection (GC), which is a garbagegcollection module in runtime, performs garbage collection on objects that are not used in the current system, and reduces the memory burden of the system. GC trigger conditions for ART include: memory allocation fails; explicitly calling the system.gc () function; cut (trim) to heap (heap) in runtime, 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 for running services in an operating system, is a provider of basic services and is a basic requirement for system running. System _ server is

The nomenclature in (1) and other nomenclature in other operating systems is possible, but is within the scope of the term system _ server in this application if the nature is the process running the service in the operating system, being the provider of the base 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 electronic equipment. 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) device, a Personal Digital Assistant (PDA), a set-top box, and the like, corresponding to products on the market. The electronic device may also be implemented as a communication terminal having a communication module, and the communication terminal may communicate with an external electronic device such as a server or the like or perform an operation by interworking with the external electronic device. Any electronic device having a processor and a memory and capable of executing computer instructions may 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, an exemplary structure of an electronic device and an exemplary structure of a software structure of the electronic device are first 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, the electronic device 100 may also optionally include an internal memory 121, an external memory interface 120, a display screen 194, a touch sensor 180K, a USB interface 130, a charging 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 microphone 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a SIM card interface 195, and the like, wherein the sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a Neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller may be, among other things, a neural center and a command center of the electronic device 100. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in 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 have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (general-purpose-processor interface, MIPI), a digital audio interface (digital audio interface, or digital audio interface), a digital audio interface (dvd), a digital audio interface (pda), a mobile audio interface (pda)

An input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The I2C interface is a bi-directional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SC L). in some embodiments, the processor 110 may include multiple sets of I2C buses.the processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc. via different I2C bus interfaces, for example, the processor 110 may be coupled to the touch sensor 180K via an I2C interface, such that the processor 110 and the touch sensor 180K communicate via an I2C bus interface to implement the touch function of the electronic device 100.

The I2S interface may be used for audio communication. In some embodiments, processor 110 may include 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 communicate audio signals to the wireless communication module 160 via the I2S interface, enabling answering of calls via a bluetooth headset.

The PCM interface may also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled by 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, so as to implement a function of answering a call through a 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 used for asynchronous communications. The bus may be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally 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 the audio signal to the wireless communication module 160 through a UART interface, so as to realize the function of playing music through a bluetooth headset.

MIPI interfaces may be used to connect processor 110 with peripheral devices such as display screen 194, camera 193, and the like. The MIPI interface includes a Camera Serial Interface (CSI), a display screen serial interface (DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the capture functionality of electronic device 100. The processor 110 and the display screen 194 communicate through the DSI interface to implement the display function of the electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal and may also be configured 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, a MIPI interface, and the like.

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, and may also be used to transmit data between the electronic device 100 and a peripheral device. And the earphone can also be used for connecting an earphone and playing audio through the earphone. The interface may also be used to connect other electronic devices, such as AR devices and the like.

It should be understood that the connection relationship between the modules according to the embodiment of the present invention is only illustrative, and is not limited to the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive charging 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 including 2G/3G/4G/5G wireless communication 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 disposed 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 a 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 passes the demodulated low frequency baseband signal to a baseband processor for processing.

The wireless communication module 160 may provide a solution for wireless communication applied to the electronic device 100, including wireless local area networks (W L AN), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like.

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

The display screen 194 is used to display images, videos, etc. the display screen 194 includes a display panel, the display panel may employ L CD (liquid crystal display), O L ED (organic light-emitting diode), active matrix organic light-emitting diode (AMO L ED), active matrix organic light-emitting diode (AMO L ED), flexible light-emitting diode (F L ED), minified, Micro L ED, Micro-O L ED, quantum dot light-emitting diodes (Q L ED), etc. in some embodiments, the electronic device 100 may include 1 or N display screens, 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 extend the memory capability of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music, video, etc. are saved in an external memory card.

The internal memory 121 may be used to store computer-executable program code, which includes 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 program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The storage data area may store data (such as audio data, phone book, etc.) created during use of the electronic device 100, and the like. Further, 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 (UFS), and the like.

The touch sensor 180K is 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 used to detect a touch operation applied thereto or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 194. In other embodiments, the touch sensor 180K may be disposed on a surface of the electronic device 100, different from the position of the display screen 194.

The keys 190 include a power-on key, a volume key, and the like. The keys may be mechanical keys. Or may be touch keys. The electronic apparatus 100 may receive a key input, and generate a key signal input related to user setting and function control of the electronic apparatus 100.

The software system of the electronic device 100 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the invention adopts a layered architecture

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

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the method will comprise

The system is divided into four layers, namely an application program layer, an application program framework layer and an android runtime from top to bottom (

runtime) and system libraries, and kernel layer. The Operating System (OS) of the electronic device 100 includes an application framework layer, an android runtime, 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 such as camera, gallery, calendar, phone call, map, navigation, W L AN, bluetooth, music, video, short message, etc.

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

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

The window manager is used for managing window programs. The window manager can obtain 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 it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, 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, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

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

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

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, 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, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc.

The Runtime comprises a core library and a virtual machine.

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

The core library comprises 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. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules, such as a surface manager (surface manager), a Media library (Media L ibraries), a three-dimensional graphics processing library (e.g., OpenG L ES), a 2D graphics engine (e.g., SG L), and the like.

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

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. 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.

In another embodiment, the region of the lockword can be set to be dedicated, and the content in the lockword is not required to be queried whether to be a lock or not when reading and using the lockword information.

The types of the lock include a lock-free (unlock, also written as Un L ock, etc., and not distinguished from case to case), a light lock (thinlock, also written as Thin L ock, not distinguished from case to case), and a heavy lock (fatlock, also written as Fat L ock, not distinguished from case to case).

As shown in FIG. 3, in lockless, the first row is an arbitrary 32bit lockword, where the first two left bits represent the lock state (lock status). The second row is unlocked. It can be seen that in the absence of a lock, the lock status is represented by 00 and the remaining bits are all 0's, and the sum of the remaining bits is written as 0's in the figure for simplicity, indicating that the remaining bits are all 0's.

In a light lock, the first row is an arbitrary 32bit lockword, where the first two left bits represent the lock state (lockstatus). The second row is lightly locked. It can be seen that in a light lock, the lock status is represented by 00, and the next two free bits are reserved bits, which can also be used for hash marks and the like in other embodiments. The remaining bits are divided into a number of reentrants (lockcount) and a thread identification (thread id). The number of reentries represents the number of times a particular thread continues to enter the lock without releasing the lock. The thread identification records the thread ID currently holding the light lock. In this embodiment, 12 bits are assigned to the number of reentrants, and 16 bits are assigned to the thread id. In other embodiments, other numbers of bits may be allocated to the reentrant times.

It can be seen that in relocking, the lock state is represented by 01, the next two free, reserved bits, in other implementations, may be used for hash marks and the like, the remaining bits are assigned monitor identification (monitor id), each Fat L ock has its own monitor.

FIG. 4 illustrates an embodiment of the present application providing a light lock and a heavy lock mechanism. An object's lock cannot be held by more than one thread at the same time, i.e., after a thread takes the object lock, other threads cannot acquire the lock until it releases the lock. As shown in FIG. 4, how T2 waits for the lock is explained based on whether the current state of the lock held by T1 is a light lock or a heavy lock.

a) The state of the lock is light lock

At this time, when one thread T2 blocks the lock, T2 calls sched _ yield to give the cpu right, the system adds the thread to the end of the queue, if there is no thread with a higher priority than the thread, the thread immediately resumes execution, otherwise, other threads are allowed to hold the cpu to continue execution, T2 detects the lock state when it gets the cpu again, if T1 has released the lock at this time, T2 obtains the lock, at this time, only context switching is involved, the overhead is small, context switching refers to the state of saving registers, signals and the like when queuing is removed, and the purpose is to enable normal execution of the flow when switching back. In this embodiment, the number of times sched _ yield is called by T2 during the period that T1 holds the light lock is counted, and if a certain threshold is exceeded, for example, 50 times, it indicates that the contention (contention) caused by the lock is severe, and therefore T2 will change the light lock to the heavy lock, but the holder of the heavy lock is T1.

b) The state of the lock being relocking

If the lock is a relock, when the T2 accesses the lock, the T2 enters the kernel through a futex system call and sleeps, the kernel executes a complex scheduling algorithm, and when the T1 releases the lock, the T2 thread of the blocked is awakened through the futex system call.

If the generated heavy lock can be degraded into a light lock or no lock under the condition of little competition, the system overhead can be saved, the execution speed of the protected code segment is accelerated, and the use fluency of the electronic equipment is further improved. One known approach is to uniformly downgrade relocks when allocating Memory (allocation Memory), GC. Clipping (trim) may be done to memory, including relock demotions, for example, when allocating memory, GC. All threads created by the application are suspended before the execution lock is downgraded and then resumed after downgrading. The strategy is easy to implement, but the defect is that the thread created by the application program in the running of the virtual machine needs to be paused, and if a large number of relocks needing to be degraded are accumulated at the time, the pause time is increased, and the user experience is damaged. And the time when the GC occurs is unpredictable, it is difficult to alert the user that a card pause will occur before the GC occurs. As shown in fig. 5A to 5E, a bad experience of the user may be caused due to a pause in GC. For example, as shown in fig. 5A, a user is using the electronic device to make a call with a socially high call partner. After the call is over, the user clicks on-hook, as shown in fig. 5B. The user then places the phone in a pocket, as shown in FIG. 5C. The user thinks the on-hook was successful, and the expression of the lyric in a fierce language, as shown in FIG. 5D. However, GC occurs while the call is on hook, all threads created by the application, including the call application thread, are suspended, and no on hook operation is performed, as shown in FIG. 5E. After the user puts the user in the pocket, the GC is finished, and the conversation application thread is recovered, so that the fierce language expression of the user is collected by the electronic equipment and is heard by a conversation object, and the user finds out that the user has bad use experience for the electronic equipment. As can be seen from this case, if the time can be shortened by concentrating lock degradation without GC, it can help to avoid the user's bad experience with the electronic device. The extension of the GC for centralized lock downgrades depends on how many relocks accumulate at the GC, and if there are many threads running before the GC, such as during boot-up, the lock downgrade takes longer. The lock degradation may delay the GC by up to about 200 ms.

Fig. 6 illustrates a lock operation method provided by an embodiment of the present application. An object a, for example a piece of code, is arranged in the electronic device, the thread T1 created by the application is holding the lock of this object a. Hereinafter, for clarity, the lock of an object may be referred to simply as an object lock. As mentioned above, programs in the java language may, in operation, modify objects with synchronized keywords for mutual exclusion, for example, in the form of synchronized (obj), where obj stands for object. For synchronized syntax, the Java Compiler (Java Compiler) will insert SyncEnter and SyncExit instructions at the beginning and end of its protected code segment, respectively. The java virtual machine or other operating mechanism similar to the java virtual machine, which converts java language into language understandable by the operating system, has corresponding similar MonitorEnter and MonitorExit functions as bottom layer implementation for SyncEnter and SyncExit instructions. The thread enters the MonitorExit module when the lock is released. The lock operation method provided by this embodiment is just running in the MonitorExit module. All threads created by the application need not be suspended in the execution of the lock operation method provided by the present embodiment, as in GC.

Without pausing all threads created by the application, the type of lock is checked in step 601, if it is determined to be a relock, step 602 is executed, wherein it is determined that the Object (Object) corresponding to the current lock is not used in a Java Method such as wait, sleep, etc., and is not in a conflict state (i.e., other threads are ready to block on the lock), and the lock is downgraded in step 603.

In step 601, the current state of the object lock can be judged according to the structure of lockword. If the lockword has a structure like a relock (Fatlock) in fig. 3, i.e. two bits of the lock head are 01, and the last 28 bits are monitor id, it is determined as a relock.

In step 603, the lock is downgraded. Lock downgrades include downgrading to light locks and no locks.

Fig. 7 illustrates a method for operating a lock according to an embodiment of the present application. An object a is disposed in the electronic device, for example, a piece of code, a thread T1 created by an application is holding a lock for the object a, and the state of the lock is a relock. T2 accesses the object and enters the MonitorEnter module, where the lock operation method provided by this embodiment runs. In step 701, it is determined that the lock status of the current object is relocked. The specific measure can be reading the lockword, judging whether the lockword is a heavy lock or not through the first two-bit identifier and the structure of the lockword, wherein the meaning is that whether the lockword is a heavy lock or not is judged firstly, and the program behind the last colon is allowed to be executed under the condition that the lockword is a heavy lock. In step 702, a spin lock (spinlock) is added for protection, so that other threads except T2 can not enter the spin lock protected code block temporarily, and the code block includes two pieces, one piece is a code segment for lock degradation protection and one piece is a code segment in the MonitorEnter that is ready to enter collision wait. In step 703, the state of the lock is checked again, for example, by checking lockword through the lw.getstate () function to know the lock state.

If the check in step 703 is that the lock has been downgraded, then the spin lock is cancelled in step 704 and the lock state is re-read in step 705, which may be Un L ock or Thin L ock.

If the check in step 703 is that the lock is not downgraded, then the relock conflict flag is incremented by 1 in step 706. The relock conflict flag indicates that when the current thread T1 holds the relock and is ready to be demoted, if it is found that another thread T2 has entered the code segment protected by the spin lock in the Monitorenter before T1 and is ready to conflict on the relock, T2 sets the conflict flag, and at this time, T1 detects that no demotion is done. The spin lock protection is removed in step 707. T2 enters the block state in step 708. Until T2 gets the object lock, it will not decrement the relock 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 removing spin lock protection are optional.

Example code for this embodiment is:

fig. 8 illustrates a lock operation method provided by an embodiment of the present application. The lock operation method of fig. 8 and the lock operation method of fig. 7 operate on the same object a. The lock operation method of fig. 8 runs in the MonitorExit module. Thread T1, when releasing the lock, then walks into the MonitorExit module. In step 801, T1 checks to see if there are other threads waiting for the object lock. For example, it is checked whether there is a thread that calls a java function such as wait, sleep, etc. for the relock held by T1, and there is no relock 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 it is not a hash code and there is no waiting thread then step 802 is entered. In step 802, a spin lock protection is added so that no other thread can execute the spin lock protected code segment while T1 executes the next steps in the present lock operation method. In step 803, it is checked whether the relock conflict flag is 0. A value of 0 means that no other thread enters the MonitorEnter module of the current object and is ready to block waiting while T1 is ready to release the lock. A value other than 0 means that there are other threads that were demoted into the MonitorEnter prior to T1 and are ready to block waiting on the relock. If the result of the check in step 803 is that the relock conflict flag is not 0, then the spinlock protection is cancelled in step 804, which is the result of the flow of the lock operation method in this embodiment. I.e., without degrading the relock. If the result of the check in step 803 is that the relock conflict flag is 0, then in step 805, the relock is downgraded to no lock. The method is, for example, to set lockword to zero. And the spin lock is revoked at step 806. In this embodiment, the add spin lock step 802 and the cancel spin lock steps 804 and 806 are optional. Exemplary code for this embodiment is:

fig. 9A and 9B illustrate a lock operation method provided by 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 releases the lock after running object A's code, and then walks to the MonitorExit module. Turning first to 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, indicating that an error occurs, the process of the method is ended through the 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 whether the number of reentries is 0. The number of reentries records the total number of times the thread T1 entered the MonitorEnter module for the object without releasing the current object lock. The general operating rule of the lock mechanism in the Java program is that each time MonitorExit is walked, the number of reentries is reduced by 1 until 0 is reduced, and the thread holding the lock is allowed to release the lock. If the number of reentries 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 a thread is waiting for the current object lock and at least one of the waiting threads is woken up on a thread waiting condition. If it is checked in step 902 that the number of reentrants is not 0, the number of reentrants is decremented by 1 in step 905. Following either step 904 or step 905, one proceeds to step 906 where it is determined in step 906 whether a thread has blocked on the lock or called a wait, sleep Java method. If the lock operation method exists, the flow of the lock operation method is ended, namely the lock operation method is ended without degrading the relock. Fig. 9B shows step 907 and subsequent steps. In step 907, a determination is made as to whether the lock holder identification is 0. If it is determined in step 907 that the lock holder identification is not 0, then spin lock protection is applied in step 908. In step 909, the relock is downgraded to a light lock on condition that the relock conflict flag is 0. The protection of the spin lock is removed in step 910. If the lock holder identification is determined to be 0 in step 907, then spin lock protection is applied in step 911. In step 912, the relock is downgraded to no lock if the relock conflict flag is 0. The protection of the spin lock is removed in step 913. The flow of the lock operation method ends after step 910 or step 913. The steps 908 and 911 of adding a spin lock and the steps 910 and 913 of removing a 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, fig. 8 and fig. 9A-B of the present application enables to dynamically degrade a relock that is not competitive in the process of running code by a thread, where the time of each degradation is in milliseconds, and thus the large block time of centralized lock degradation is dispersed along with the action of the thread, and does not cause the electronic device to be stuck, thereby maintaining a smooth use experience of a user. For example, an electronic device running the lock operation method provided by the embodiment of the present application is compared with an electronic device running a google art system without the lock operation method. After the object obj is modified by using synchronized keywords, the compiler inserts SyncEnter and SyncExit into the head and tail of the code of the object, and the SyncEnter and the SyncExit are respectively realized by corresponding to a MonitorExit function and a MonitorExit function at the bottom layer. As shown in the following code:

original Java code:

statement 1; // statement1

Modified (obj) object obj with a synchronized keyword

Codes sequence; // code sequence

}

Statement 2; // statement2

Compiled synchronized becomes a call 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 performances of electronic devices with and without the lock operation method provided by the embodiment of the present application, the number of times of lock downgrade and the number of relocks are mainly compared, but not the execution time, because the difference of code sequence execution time is caused by the difference of compilers and system differences, etc.

Comparing the number of times of light lock, heavy lock and lock degradation respectively for the electronic device X running the native Art and the electronic device Y running the lock operation method provided by the embodiment of the application after starting from Zygote and SystemServer to 15 seconds, 45 seconds and 5 minutes in a cumulative way during testing startup:

1)15 seconds:

electronic device	Number of light locks	Number of relocks	Number of relocking downgrades
				X	574224	231660	0
Y	700025	15699	2183

2)45 seconds:

electronic device	Number of light locks	Number of relocks	Number of relocking downgrades
				X	691128	285566	0
Y	870103	18499	2850

3) 5 minutes are accumulated:

from the test results, the following conclusions can be drawn:

1) the dynamic lock degradation of the electronic device Y can release the system pressure in time, the degradation times are more than 3000 times, and the electronic device X does not execute the lock degradation, so that the system pressure cannot be released from the relock. Compared with the relocking generated by the electronic equipment X, the relocking generated by the electronic equipment Y is reduced by more than thirty-thousand times, and 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 device X is about one hundred and one hundred thousand, the total number of the light locks and the heavy locks of the electronic device Y is about one hundred and sixty thousand, and the total number is almost the same, which indicates that the number of the lock objects is equivalent. One hundred and forty thousand of the total locks of the electronic device Y are light locks, and only less than twenty thousand are heavy locks. Nearly eighty thousand of the total number of locks of the electronic device X are light locks, and thirty twenty thousand are heavy locks. The proportion of light and heavy locks also shows that the lock operation method provided by the embodiment of the application can degrade the heavy locks in time and relieve the system pressure;

3) a centralized degradation in the electronic device X, such as over a five minute or later period, may involve pausing, resuming operation, and may result in severe downtime.

When a thread enters MonitorEnter before other threads for the first time, a lock is obtained and changed from the initial state (Un L ock) to Thin L ock;

when the thread entry enters again, L ockCount + +, if L ockCount has exceeded the maximum value that can be represented, the lock is upgraded from Thin L ock to Fat L ock,

if the other threads enter and the lock state is Thin L ock, the thread scheduled _ yield waits for a certain number of times, and if the waiting time exceeds a certain number of times, the lock is upgraded from Thin L ock to Fat L ock;

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

in a MonitorEnter Fat L ock scene, under the Spin L ock protection, L ock word is read again and the state is detected, if no other Thread Deflate exists at the moment, a context Flag is set, a normal L ock flow is executed, a lock function is taken to be locked or waits, if other Thread Deflate exists, the Un L ock or the Thin L ock state is taken again, and the Spin L ock protection is exited.

When the thread enters and the lock is in a Un L ock state, an error is made, and an exception is thrown;

when a thread enters and the lock is in the Thin L ock state, L ockCount- - -if L ockCount is already 0, the lock is set to Un L ock state;

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

in a scene of MonitorExit- > Unlock Fat L ock, detecting that the current lock Wait Number is empty, namely no Thread for Java methods such as Wait, sleep and the like exists and no conflict exists, counting the Deflate Number, if reaching a certain Number of times, detecting whether other Thread prior to the current Thread Deflate exists under the protection of Spin L ock, if not, executing conversion from Fat L ock to Un L ock or Thin L ock, and after degradation (Deflate) is finished, exiting Spin L ock protection.

Embodiments of the present application further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to enable the electronic device to implement the lock operation method provided in any embodiment of the present application.

Embodiments of the present application further provide a computer storage medium, which includes computer instructions, and when the computer instructions are executed on an electronic device, the electronic device is caused to execute the lock operation method provided in any embodiment of the present application.

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

The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, e.g., from one website site, computer, server, or data center, via wired (e.g., coaxial cable, fiber optics, digital subscriber (DS L)) or wireless (e.g., infrared, wireless, microwave, etc.) means to another website site, computer, server, or data center, the computer-readable storage medium may be any computer-accessible medium, or integrated Solid State or multiple Solid State storage media (e.g., floppy Disk, optical Disk, or optical storage media, such as a Solid State storage medium, or optical storage media, such as a floppy Disk, optical storage media, or optical storage media.

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 implementation. 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 is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed 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 can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into 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 or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: u disk, removable hard disk, read only memory, random access memory, magnetic or optical disk, etc. for storing program codes.

The above description is only for the 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 conceive of the changes or substitutions within the technical scope of the present application, and shall 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, the lock operation method being executed on an electronic device, a first object being arranged on the electronic device, the first object being a piece of code, at least one application being arranged on the electronic device, 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 recording a state of the lock, the lock operation method comprising performing without suspending the first thread: step 1, checking the state of the lock of the first object; step 2, under the condition that the lock of the first object is relocked, judging whether other threads wait for the lock of the first object; and 3, degrading the lock of the first object under the condition that no other thread waits for the lock of the first object in the step 2.

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 method of lock operation according to any of claims 1 to 2, wherein said steps 1, 2 and 3 are performed in a MonitorExit module.

4. The lock operation method according to any of the preceding claims, wherein the condition that no other thread is waiting for the lock of the first object in step 3 is that no other thread has been blocked on the lock of the first object or that a java method wait or s leep has been invoked.

5. The lock operation method according to any one of the preceding claims, further comprising executing in a MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded to be lock-free in the step 5, enabling the first thread to take a lock-free flow for the lock of the first object; step 7, adding 1 to a relocking conflict mark under the condition that the lock is judged not to be degraded to be lock-free in the step 5; step 8, blocking the first thread under the condition that the relock conflict mark is increased by 1 in the step 7; and 9, subtracting 1 from the relock conflict mark under the condition that the first thread acquires the lock of the first object.

6. The lock operation method according to any one of the preceding claims, further comprising: in step 2, checking whether the lock word of the first object lock is a hash code; in the step 3, 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, whether the relock collision flag is 0 is checked, and if the relock collision flag is 0, the lock of the first object is downgraded to no lock.

7. A lock operation method, which runs on an electronic device on which a first object is arranged, the first object being a piece of code, at least one application program being arranged on the electronic device, the at least one application program having a first thread that holds 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 number of reentry times is 0; step 2, under the condition that the number of times of reentry is judged to be 0 in the step 1, degrading the lock of the first object to be lock-free under the condition that a re-locking conflict mark is 0; and 3, degrading the lock of the first object to be a light lock under the condition that the re-locking conflict mark is 0 under the condition that the re-entry times are judged to be not 0 in the step 1.

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 method of any of claims 7 to 8, wherein said steps 1, 2 and 3 are performed in a MonitorExit module.

10. The lock operation method according to any one of claims 7 to 8, further comprising performing in a MonitorEnter 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 relocking in the step 4; step 6, under the condition that the lock is judged to be degraded in the step 5, the lock state is obtained again; step 7, adding 1 to the relock conflict mark under the condition that the lock is judged not to be degraded in the step 5; step 8, blocking the first thread under the condition that the relock conflict mark is added with 1 in the step 7; and 9, subtracting 1 from the relock conflict mark under the condition that the first thread acquires 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 carry out 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 a lock operation method according to any one of claims 1 to 10.

13. A computer program product which, when run on a computer, causes the computer to perform a lock operation method according to any one of claims 1 to 10.