A JAVA virtual machine memory allocation system and method

Abstract

The present invention relates to the field of computer information technology, and discloses a JAVA virtual machine memory allocation system and method, which realizes dynamic and rational allocation of memory resources in different application scenarios to meet the changing needs of application scenarios. The system includes: a first determination module, which is used to determine the memory value that each component of the application software system needs to occupy according to the specification index of the application software system deployed in the actual application scenario; a second determination module, which is used to determine the memory value that the third-party component needs to occupy under all the specification index items of each component of the application software system; a memory allocation module, which is used to allocate memory values ​​to the corresponding components according to the determined memory values ​​that each component of the application software system needs to occupy and the memory values ​​that the third-party components need to occupy.

Description

Technical Field

[0001] The present invention relates to the field of computer information technology, and in particular to a JAVA virtual machine memory allocation system and method. Background Art

[0002] In a large-scale solution system developed in JAVA language, multiple JAVA processes (referred to as components) collaborate to form an application system, which involves the need to allocate JVM memory for different components. The allocation method commonly used in the prior art is to pre-specify the minimum and maximum memory required by each component. This allocation method has the following problems:

[0003] (1) In different application scenarios, the system needs to meet different specifications, resulting in different memory sizes required by each component. The method of pre-specifying the memory of each component cannot meet the differences in component memory requirements caused by specification changes in different scenarios. As a result, it is necessary to manually configure the memory values ​​of different components for different application scenarios. At the same time, different versions need to be provided for different application scenarios. The system cannot achieve universal adaptation well.

[0004] (2) When there are components added or removed in the system, it is necessary to manually reallocate memory for all components, otherwise unreasonable component memory allocation may occur. In particular, when certain components are not started by license control and no human intervention is possible, other started components cannot use the freed memory, resulting in a situation where there is sufficient memory but the performance cannot meet the requirements.

[0005] (3) For some test or trial versions, when server resources are limited in the customer test environment, the memory usage of the component cannot be automatically reduced, resulting in the inability to test normally.

[0006] (4) Since the memory allocated to different specific scenarios cannot be simply merged to form the memory allocation of mixed scenarios, in some mixed application scenarios, the system elasticity will drop sharply.

[0007] Therefore, how to achieve dynamic and rational allocation of memory resources in different application scenarios to meet the changing needs of application scenarios is a technical problem that needs to be solved urgently. Summary of the invention

[0008] The technical problem to be solved by the present invention is to propose a JAVA virtual machine memory allocation system and method to achieve dynamic and rational allocation of memory resources in different application scenarios to meet the changing needs of application scenarios.

[0009] The technical solution adopted by the present invention to solve the above technical problems is:

[0010] On the one hand, an embodiment of the present invention provides a JAVA virtual machine memory allocation system, including:

[0011] A first determination module is used to determine the memory value required to be occupied by each component of the application software system according to the specification indicators of the deployed application software system;

[0012] The second determination module is used to determine the memory value that the third-party component needs to occupy under all specification indicators of the respective components of the application software system;

[0013] The memory allocation module is used to allocate memory values ​​to corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components.

[0014] As a further optimization, the memory allocation module is further used to: calculate the total memory required by the application software system according to the memory values ​​required to be occupied by the components of the application software system, the memory values ​​required to be occupied by the third-party components, and the memory required to be occupied by the operating system of the application software system;

[0015] Calculate the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system;

[0016] The remaining memory is allocated to the native components and third-party components of the application software system.

[0017] As a further optimization, the first determining module is specifically used to:

[0018] Determine the baseline memory value occupied by each component of the application software system under its baseline specifications;

[0019] The actual memory value required to be occupied by each component is determined according to the actual specification index items of the deployed application software system and the baseline memory value occupied under the corresponding baseline specification.

[0020] As a further optimization, the method for determining the baseline memory value occupied by each component of the application software system under its baseline specification includes:

[0021] Before the application software system leaves the factory, the memory usage values ​​of each component of the system are sampled multiple times;

[0022] Calculate the average memory usage of the baseline specification indicator items that affect memory resource usage under each component of the system;

[0023] The baseline memory value occupied by the corresponding built-in component under its baseline specification is obtained by summing up the average memory usage of all baseline specification indicator items under each built-in component.

[0024] As a further optimization, the second determination module is specifically used to:

[0025] According to the proportional relationship between the memory occupied by the third-party component and the memory occupied by the native component under its corresponding specification index item, the memory value that the third-party component needs to occupy under all specification index items of each component in the system is calculated.

[0026] On the other hand, an embodiment of the present invention further provides a JAVA virtual machine memory allocation method, comprising the following steps:

[0027] a. Determine the memory value required to be occupied by each component of the application software system according to the specifications of the deployed application software system;

[0028] b. Determine the memory value that the third-party components need to occupy under all specification indicators of the respective components of the application software system;

[0029] c. Allocate memory values ​​to the corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components.

[0030] As a further optimization, the method further comprises the steps of:

[0031] d. Calculate the total memory required by the application software system based on the memory values ​​required by the components of the application software system, the memory values ​​required by third-party components, and the memory required by the operating system of the application software system;

[0032] Calculate the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system;

[0033] The remaining memory is allocated to the native components and third-party components of the application software system.

[0034] As a further optimization, step a specifically includes:

[0035] a1. Determine the baseline memory value occupied by each component of the application software system under its baseline specifications;

[0036] a2. Determine the actual memory value that each component needs to occupy based on the actual specification indicators of the deployed application software system and the baseline memory value occupied under the corresponding baseline specification.

[0037] As a further optimization, step a1 specifically includes:

[0038] a11. Before the application software system leaves the factory, the memory usage values ​​of each component of the system are sampled several times:

[0039] Assume that the application software system includes n components, where Cn represents the nth component, there are m baseline specification indicators under the Cn component that affect its memory usage, and Jm(Cn) represents the mth baseline specification indicator of the Cn component;

[0040] The memory usage value of each component of the system is sampled multiple times, and the memory usage value of the Cn component obtained by the k-th sampling is Gk(Cn);

[0041] a12. Calculate the average memory usage of the baseline specification indicators that affect memory resource usage for each component in the system:

[0042] The calculation method of the average memory usage G(Jm(Cn)) of the mth baseline specification indicator item Jm(Cn) of the Cn component is:

[0043]

[0044] a13. By summing up the average memory usage of all baseline specification indicator items under each built-in component, obtain the baseline memory value occupied by the corresponding built-in component under its baseline specification:

[0045] The baseline memory value G(Cn) occupied by the Cn component under its baseline specifications is calculated as follows:

[0046]

[0047] As a further optimization, in step a2, determining the memory value actually required to be occupied by each band component specifically includes:

[0048] For the Cn component, the actual memory value G′(Cn) required is calculated as follows:

[0049]

[0050] Among them, Sm(Cn) is the mth specification indicator of component Cn of the application software system in the actual application scenario.

[0051] As a further optimization, step b specifically includes:

[0052] According to the ratio between the memory occupied by the third-party component and the memory occupied by the built-in component under its corresponding specification index item, the memory value that the third-party component needs to occupy under all specification index items of each component in the system is calculated:

[0053]

[0054] Among them, G′(Tn) is the memory value actually required by the third-party component under all specification indicators of the Cn component, and Rm represents the proportional relationship between the memory occupied by the third-party component and the mth specification indicator item in the Cn component.

[0055] As a further optimization, in step d, the total memory required by the application software system is calculated as follows:

[0056]

[0057] Among them, G′ is the total memory required by the application software system, Gs is the physical memory provided by the actual application scenario, and Rs is the proportion of the memory required by the operating system in the physical memory;

[0058] The remaining memory is calculated as follows:

[0059] L = Gs - G′;

[0060] The calculation method for allocating the remaining memory to the built-in components and third-party components of the application software system is as follows:

[0061] The third-party component is regarded as a component, and the remaining memory L is evenly distributed between this component and each native component.

[0062] The beneficial effects of the present invention are:

[0063] 1. The system can dynamically calculate the memory required according to the different specification requirements in the actual scenarios of customers or the number of authorization specifications controlled by the license, and can adapt to the authorization differences in different scenarios such as independent solution scenarios and hybrid solution scenarios;

[0064] 2. Based on the specifications, the specification index values ​​that the system must support can be calculated, and the required memory resources can be calculated based on the specification index values. If the current resources are insufficient, resource demands can be made to customers in advance, and the required memory resource size can be given more clearly; when the current resources are sufficient, the surplus memory can be fully utilized to improve system performance;

[0065] 3. It can reasonably allocate the memory required by each component of the entire system to avoid improper allocation that causes insufficient memory in some components and leads to system crash, and excessive memory allocation in some components leads to serious waste of memory resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 It is a structural block diagram of the JAVA virtual machine memory allocation system in the present invention;

[0067] Figure 2 This is a flow chart of the JAVA virtual machine memory allocation method in the present invention. DETAILED DESCRIPTION

[0068] The present invention aims to propose a JAVA virtual machine memory allocation system and method to achieve dynamic and rational allocation of memory resources in different application scenarios to meet the changing needs of application scenarios. The basic idea is that the operation of the application software system will inevitably occupy memory, and the memory occupation is proportional to the specification index of the system. Therefore, the present invention automatically calculates the memory occupation value of the component according to the specifications of different application scenarios that need to be met, thereby forming the memory value required by the entire system under the scenario and corresponding specifications.

[0069] like Figure 1 As shown, the JAVA virtual machine memory allocation system in the present invention includes a first determination module, a second determination module and a memory allocation module;

[0070] The first determination module is used to determine the memory value required to be occupied by each component of the application software system according to the specification indicators of the application software system deployed in the actual application scenario;

[0071] The second determination module is used to determine the memory value that the third-party component needs to occupy under all specification indicators of the respective components of the application software system;

[0072] The memory allocation module is used to allocate memory values ​​to corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components.

[0073] In an actual scenario, after allocating memory, if there is still some physical memory left, the remaining memory can be allocated to various components to improve the performance of the system. Therefore, the memory allocation module is also used to:

[0074] Calculate the total memory required by the application software system according to the memory values ​​required by the components of the application software system, the memory values ​​required by the third-party components, and the memory required by the operating system of the application software system;

[0075] Calculate the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system;

[0076] The remaining memory is allocated to the native components and third-party components of the application software system.

[0077] Based on the above memory allocation system, the JAVA virtual machine memory allocation method implemented by the present invention is as follows: Figure 2 As shown, it includes the following steps:

[0078] Step 1: Determine the memory value required to be occupied by each component of the application software system according to the specification indicators of the application software system deployed in the actual application scenario;

[0079] In this step, firstly, the baseline memory value occupied by each component of the application software system under its baseline specification is determined;

[0080] Then, the memory value actually required to be occupied by each component is determined according to the actual specification index items of the application software system deployed in the actual application scenario and the baseline memory value occupied under the corresponding baseline specification.

[0081] Assume that the application software system is composed of n components, and Cn represents the nth component; Assume that the baseline specification index of component Cn at the time of leaving the factory (referring to the specification index value of the product in the universal application scenario at the time of leaving the factory) is J(Cn); Assume that the memory usage of component Cn under the baseline specification index J(Cn) is G(J(Cn));

[0082] Generally speaking, a baseline specification is related to the data structure that constitutes the baseline specification, and its memory usage also corresponds to the memory usage of the data structure. Assuming that the main data structure that constitutes the baseline specification indicator occupies B bytes of memory when single data is used, then theoretically, the memory required under the J(Cn) specification is Gb(J(Cn)) = J(Cn)*B bytes. For example: a baseline specification is that the number of manageable users is 100, and the memory occupied by each user data is 200 bytes, then the theoretical memory required under the baseline specification is 100*200 bytes;

[0083] However, it should be noted that this data is theoretical data. In actual applications, due to factors such as the developer's skill level, business logic complexity, and server performance of the application system, the same data may be redundantly stored or temporarily stored multiple times, or memory may accumulate due to slow program processing. Therefore, the actual memory usage is inconsistent with the theoretical data. Therefore, it is necessary to pre-test and simulate multiple sets of data for average sampling before the system is released to obtain the most accurate baseline memory value.

[0084] Assume that component Cn has m specification indicators that affect its memory usage, Jm(Cn) represents the mth baseline specification indicator of component Cn; Assume that k samplings are performed, the memory result of each sampling of component Cn is Gk(Cn);

[0085] Next, we can calculate the average memory usage of the baseline specification indicators that affect memory resource usage under each component of the system:

[0086] The calculation method of the average memory usage G(Jm(Cn)) of the mth baseline specification indicator item Jm(Cn) of the Cn component is:

[0087]

[0088] Among them, Gk(Jm(Cn)) represents the memory usage value of the mth baseline specification indicator of the Cn component in the Kth sampling. Since it is difficult to sample and obtain this value, we can use the theoretical memory ratio between each indicator item for conversion. The formula is as follows:

[0089]

[0090] Among them, Bm is the theoretical value of the memory required by a single data structure in the mth indicator item.

[0091] After using Gk(Jm(Cn)) to calculate the average memory usage G(Jm(Cn)) of the mth baseline specification indicator item Jm(Cn) of the Cn component, we can sum the average memory usage of all baseline specification indicator items under each built-in component to obtain the baseline memory value occupied by the corresponding built-in component under its baseline specification:

[0092] The baseline memory value G(Cn) occupied by the Cn component under its baseline specifications is calculated as follows:

[0093]

[0094] Step 2: Determine the memory value that the third-party components need to occupy under all specification indicators of the components in the application software system;

[0095] Assume that the components that make up the application software system also include some dependent third-party components (here all third-party components are considered as one component to facilitate the calculation of memory relationships. Of course, they can also be subdivided according to the built-in components that make up the application system, but it is a little more complicated. In actual use, third-party components other than cache are not the main body of memory occupation, so the necessity of considering them is not too great), for example: cache Redis components, etc. Assuming that there is a certain proportional relationship between the memory occupation of these components and the system specification indicators, the memory occupied by third-party components is:

[0096]

[0097] Where Rm represents the ratio of the memory occupied by the third-party component and the mth specification indicator item in the Cn component. When it is 0, it means there is no relationship. G(Tn) represents the total memory occupied by the third-party component under all specification indicator items of the Cn component.

[0098] Step 3: Allocate memory values ​​to the corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components;

[0099] In this step, in actual application scenarios, we can allocate corresponding memory sizes to each component of the calculation according to the memory it needs to occupy.

[0100] Step 4: Calculate the total memory required by the application software system, and obtain the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system; allocate the remaining memory to the built-in components and third-party components of the application software system.

[0101] The memory required by the application software system includes not only the memory occupied by its own components and the memory occupied by third-party components, but also the memory occupied by the operating system. Assuming that the memory required by the operating system is fixed at Rs% of the server's physical memory, the memory occupied by the application software system can be calculated as:

[0102]

[0103] Gs indicates the total physical memory of the server.

[0104] From this, we calculated the memory requirements occupied by the application software system.

[0105] In actual application scenarios, if the physical memory provided by the user still has surplus after meeting the memory requirements of the application software system, the remaining memory can be allocated to various components to improve system performance.

[0106] Specifically, remaining memory = actual physical memory - memory occupied by the application software system. If we regard third-party components as one component, plus the n components that come with the application software system, there are a total of n+1 components. We can evenly distribute the remaining memory to these n+1 components.

[0107] Example:

[0108] Assume that an application software system consists of two components, A and B, and uses a third-party component C. Assume that component A has two baseline specification indicators that affect memory resource usage, namely indicator 1 and indicator 2: indicator 1 is the number of users accessing the system, which is assumed to be 1,000 users; indicator 2 is the number of manageable user terminals, which is assumed to be 2,000 terminals; Assume that component B has one baseline specification indicator that affects memory resource usage, which is assumed to be indicator 3, and indicator 3 is the number of manageable devices, which is assumed to be 5,000 devices; Assume that third-party component C is used to cache user, terminal, device and other data to speed up the query speed of the system. Assume that all user data is stored, and its cache memory usage ratio is 100%. Assume that only 20% of the terminal data needs to be stored in the cache, and only 50% of the device data needs to be stored in the cache. Assume that the data structure involved in indicator 1 is mainly the user data structure, which is composed of user data metadata, such as user name, user phone number, user address and other information. According to the metadata that constitutes the user data structure, the memory size required for a single user data structure can be simply calculated. Assume that a single user data occupies 200 bytes of memory; assume that a single terminal data occupies 500 bytes of memory; assume that a single device data occupies 1000 bytes of memory.

[0109] Assume that five samplings are performed before the system leaves the factory. The sampling results of component A and component B are as follows:

[0110] Table 1: Component A sampling results

[0111] Sampling times Memory occupied by components (in MB) first 64 Second time 66 The third time 62 Fourth 68 Fifth 67

[0112] Table 2: Component B sampling results

[0113] Sampling times Memory occupied by components (in MB) first 70 Second time 72 The third time 78 Fourth 75 Fifth 74

[0114] The memory baseline value occupied by the corresponding indicator item at each sampling can be calculated according to the following formula:

[0115]

[0116] Taking the first sampling of indicator 1 as an example, its calculation method is:

[0117] 64MB*(1000 user data*200 bytes / each user data ÷(1000 user data*200 bytes / each user data + 2000 terminal data*500 bytes / each terminal data))=64MB*(2 / 12)=10.7MB

[0118] This method can be used to calculate the sampling results of each indicator item in the component:

[0119] Table 3: Sampling results of each indicator item of component A

[0120] Sampling times Memory value occupied by indicator 1 (MB) Memory value occupied by indicator 2 (MB) first 10.7 53.3 Second time 11 55 The third time 10.3 51.7 Fourth 11.3 56.7 Fifth 11.2 55.8

[0121] Therefore, according to the following formula

[0122]

[0123] The average sampling value of component A under index 1 is calculated as: G(J1(CA))=(10.7+11+10.3+11.3+11.2) / 5=10.9MB. Similarly, the average sampling value of component A under index 2 can be calculated as G(J2(CA))=54.5MB.

[0124] Component B has only one indicator item, namely indicator 3, so the sampling data of indicator 3 of component B is the sampling data of component B. Then the average sampling value of component B under indicator 3 is: G(J3(CB)) = 73.8MB

[0125] According to the following formula:

[0126]

[0127] It can be calculated that at the time of shipment, based on the factory baseline specifications, the baseline memory occupied by the system's own components is:

[0128] G(J1(CA))+G(J2(CA))+G(J3(CB))=139.2MB

[0129] The memory required by third-party components is calculated using the following formula:

[0130]

[0131] Assuming that all user data is stored, the cache memory usage ratio is 100%. Assuming that only 20% of the terminal data needs to be stored in the cache and only 50% of the device data needs to be stored in the cache, the baseline memory requirement for third-party components when leaving the factory is:

[0132] G(J1(CA))*100%+G(J2(CA))*20%+G(J3(CB))*50%=10.9*100%+54.5*20%+73.8*50%=58.7MB

[0133] Then, when the application software system leaves the factory, under the factory specifications, the minimum physical memory required is:

[0134]

[0135] That is: G(Cn)+G(Tn)=139.2+58.7=197.9MB. Assuming that 10% of the system's physical memory is provided for the operating system, the customer needs to provide at least 256MB of physical memory.

[0136] Assume that in a certain customer scenario, the customer provides a server with 32G memory for deploying the application software system. Assume that the actual indicator 1 is to manage 20,000 users, indicator 2 is to manage 40,000 terminals, and indicator 3 is to manage 10,000 devices.

[0137] The following formula can be used to calculate the actual memory occupied by the system's built-in components under the user's required specifications:

[0138]

[0139]

[0140] The memory required by third-party components is:

[0141]

[0142] Then, in this customer's application scenario, the application software system requires at least the following physical memory under the customer's specifications:

[0143]

[0144] That is: 1455.6+509.8=1965.4MB. Assuming that 10% of the system's physical memory is provided to the operating system, the customer needs to provide at least 2.5G of physical memory.

[0145] In fact, the customer provides 32G of physical memory, so the remaining memory can be evenly distributed to various components to improve system performance. Assuming that 10% of the physical memory is allocated to the operating system, then in order to meet the basic memory requirements of the application software system, there is still: L = 32 * 1024MB * (1-10%) - 1965.4MB = 27525.8MB

[0146] According to the formula: Gt(Cn)=G′(Cn)+L / (n+1), n+1 represents n built-in components plus 1 unified third-party component.

[0147] It can be concluded that the actual memory size that component A can allocate is:

[0148] Gt(CA)=G′(CA)+L / (n+1)

[0149] =S1(CA)*G(J1(CA)) / J1(CA)+S2(CA)*G(J2(CA)) / J2(CA)+L / (n+1)

[0150] =20000*10.9 / 1000+40000*54.5 / 2000+27525.8 / (2+1)

[0151] =1308+9175.3

[0152] =10483.3MB

[0153] The actual memory size that component B can allocate is:

[0154] Gt(CB)=G′(CB)+L / (n+1)

[0155] =S3(CB)*G(J3(CB)) / J3(CB)+L / (n+1)

[0156] =10000*73.8 / 5000+27525.8 / (2+1)

[0157] =147.6+9175.3

[0158] =9322.9MB

[0159] The memory that can be allocated by third-party components is:

[0160] Gt(Tn)=G′(Tn)+L / (n+1)

[0161] =509.8+9175.3

[0162] =9685.1MB

[0163] Finally, in the customer scenario, under the specified indicator items and the physical memory provided by the customer, the memory allocation of each component and the operating system is as shown in the following table:

[0164] Table 4: Memory allocation table for each component and operating system

[0165]

[0166] So far, this embodiment has achieved dynamic and rational allocation of memory resources.

Claims

1. A JAVA virtual machine memory allocation system, characterized in that: include: The first determination module is used to determine the baseline memory value occupied by each component of the application software system under its baseline specification, and determine the memory value actually required to be occupied by each component according to the actual specification index items of the deployed application software system and the baseline memory value occupied under the corresponding baseline specification; The second determination module is used to determine the memory value that the third-party component needs to occupy under all specification indicators of the respective components of the application software system; The memory allocation module is used to allocate memory values ​​to corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components.

2. The JAVA virtual machine memory allocation system according to claim 1, characterized in that: The memory allocation module is also used for: Calculate the total memory required by the application software system according to the memory values ​​required to be occupied by the components of the application software system, the memory values ​​required to be occupied by the third-party components, and the memory required to be occupied by the operating system of the application software system; Calculate the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system; The remaining memory is allocated to the native components and third-party components of the application software system.

3. The JAVA virtual machine memory allocation system according to claim 1, characterized in that: The method for determining the baseline memory value occupied by each component of the application software system under its baseline specification includes: Before the application software system leaves the factory, the memory usage values ​​of each component of the system are sampled multiple times; Calculate the average memory usage of the baseline specification indicator items that affect memory resource usage under each component of the system; The baseline memory value occupied by the corresponding built-in component under its baseline specification is obtained by summing up the average memory usage of all baseline specification indicator items under each built-in component.

4. The JAVA virtual machine memory allocation system according to any one of claims 1 to 3, characterized in that: The second determining module is specifically used to: According to the proportional relationship between the memory occupied by the third-party component and the memory occupied by the native component under its corresponding specification index item, the memory value that the third-party component needs to occupy under all specification index items of each component in the system is calculated.

5. A JAVA virtual machine memory allocation method, characterized in that: The following steps are involved: a. Determine the memory value required by each component of the application software system according to the specifications of the deployed application software system, including: a1. Determine the baseline memory value occupied by each component of the application software system under its baseline specifications; a2. Determine the actual memory value required to be occupied by each component according to the actual specification indicators of the deployed application software system and the baseline memory value occupied under the corresponding baseline specification; b. Determine the memory value that the third-party components need to occupy under all specification indicators of the respective components of the application software system; c. Allocate memory values ​​to the corresponding components according to the determined memory values ​​required to be occupied by the respective components of the application software system and the memory values ​​required to be occupied by the third-party components.

6. The JAVA virtual machine memory allocation method according to claim 5, characterized in that: The method further comprises the steps of: d. Calculate the total memory required by the application software system based on the memory values ​​required by the components of the application software system, the memory values ​​required by third-party components, and the memory required by the operating system of the application software system; Calculate the remaining memory based on the physical memory provided by the actual application scenario and the total memory required by the application software system; The remaining memory is allocated to the native components and third-party components of the application software system.

7. The JAVA virtual machine memory allocation method according to claim 6, characterized in that: The step a1 specifically includes: a11. Before the application software system leaves the factory, the memory usage values ​​of each component of the system are sampled several times: Assume that the application software system includes n components, where Cn represents the nth component, there are m baseline specification indicators under the Cn component that affect its memory usage, and Jm(Cn) represents the mth baseline specification indicator of the Cn component; The memory usage value of each component of the system is sampled multiple times, and the memory usage value of the Cn component obtained by the k-th sampling is Gk(Cn); a12. Calculate the average memory usage of the baseline specification indicators that affect memory resource usage for each component in the system: The calculation method of the average memory usage G(Jm(Cn)) of the mth baseline specification indicator item Jm(Cn) of the Cn component is: a13. By summing up the average memory usage of all baseline specification indicator items under each built-in component, obtain the baseline memory value occupied by the corresponding built-in component under its baseline specification: The baseline memory value G(Cn) occupied by the Cn component under its baseline specifications is calculated as follows:

8. The JAVA virtual machine memory allocation method according to claim 7, characterized in that: In step a2, the step of determining the memory value actually required to be occupied by each component specifically includes: For the Cn component, the actual memory value G′(Cn) required is calculated as follows: Wherein, Sm(Cn) is the mth specification indicator of component Cn of the application software system.

9. The JAVA virtual machine memory allocation method according to claim 8, characterized in that: The step b specifically comprises: According to the ratio between the memory occupied by the third-party component and the memory occupied by the built-in component under its corresponding specification index item, the memory value that the third-party component needs to occupy under all specification index items of each component in the system is calculated: Among them, G′(Tn) is the memory value actually required by the third-party component under all specification indicators of the Cn component, and Rm represents the proportional relationship between the memory occupied by the third-party component and the mth specification indicator item in the Cn component.

10. The JAVA virtual machine memory allocation method according to claim 9, characterized in that: In step d, the total memory required by the application software system is calculated as follows: Among them, G′ is the total memory required by the application software system, Gs is the physical memory provided by the actual application scenario, and Rs is the proportion of the memory required by the operating system in the physical memory; The remaining memory is calculated as follows: L = Gs - G′; The calculation method for allocating the remaining memory to the built-in components and third-party components of the application software system is as follows: The third-party component is regarded as a component, and the remaining memory L is evenly distributed between this component and each native component.

Images