Simulation engine data interaction method and system based on configuration reflection and method cache

Abstract

The application relates to the technical fields of electromagnetic environment effect simulation and computer data processing, and discloses a simulation engine data interaction method and system based on configuration reflection and method caching. The method comprises the following steps: analyzing a structured configuration file to obtain an interaction mapping relationship list, a model definition list and a time step; creating a model instance and generating an instance mapping table according to needs; reading the interaction mapping relationship list, obtaining a write-in method Method object of a target instance, and storing the source identifier, the target identifier and the data field name into a hash mapping table as keys; advancing a simulation clock according to the time step, traversing the interaction mapping relationship list at each beat, for each record, obtaining a source instance and a target instance from the instance mapping table, splicing a getter method name according to the data field name and reflecting to obtain output data, retrieving the Method object from the hash mapping table, reflecting and injecting the data into the target instance through invoke, and completing the data interaction between models. The application improves the iterative verification efficiency of the simulation system.

Description

Technical Field

[0001] This application relates to the fields of electromagnetic environment effect simulation and computer data processing technology, and in particular to a simulation engine data interaction method and system based on configurable reflection and method caching for strong electromagnetic environments. It is especially suitable for simulation application scenarios such as radar radiation field prediction, electromagnetic compatibility analysis of electronic equipment, and electromagnetic pulse effect deduction under complex electromagnetic environments. Background Technology

[0002] In simulations of strong electromagnetic environments, developers typically explicitly call specific methods of the cable-coupled model or antenna receiver model directly through object references when writing the source code for radar radiation source models or high-power microwave source models. As the simulation time step progresses, the solver calculates the spatial field distribution and coupling response sequentially according to the order determined at compile time.

[0003] Some improved electromagnetic simulation software uses XML or JSON files to describe the relationships between models. During the initialization phase, the simulation engine generates a fixed Java object reference graph by parsing this configuration file, and maintains this graph unchanged throughout the entire simulation run; the data interaction paths cannot be changed during runtime.

[0004] As the complexity of simulation application scenarios increases, especially in scenarios requiring high-frequency iterative verification of model algorithms or dynamic adjustment of simulation topology, the existing technical solutions mentioned above reveal the following technical defects: 1) Severe interface coupling: The model source code explicitly depends on the specific class definitions and methods of the interaction model. Changes in requirements require modification of the source code, recompilation, and restart of the JVM, generating a large amount of non-computational waiting time and reducing the effective resource utilization rate; 2) Redundant memory usage: Hard-coded or static dependency injection will preload all model classes under the classpath, causing unnecessary memory usage and limiting the maximum concurrent capacity of a single-node simulation model; 3) Reflection performance loss: Conventional reflection repeatedly searches for methods in each cycle, resulting in high time complexity and failing to meet the requirements of real-time simulation cycle advancement. Summary of the Invention

[0005] In view of this, this application provides a simulation engine data interaction method and system based on configurable reflection and method caching. It is applied to the simulation system for constructing strong electromagnetic environments and analyzing electromagnetic coupling effects. It realizes dynamic mapping and scheduling control of data interaction between multi-physics simulation models based on Java reflection mechanism and structured configuration files. It is especially suitable for specific simulation application scenarios such as radar radiation field prediction, electromagnetic compatibility (EMC) analysis of electronic equipment, and electromagnetic pulse effect deduction under complex electromagnetic environments.

[0006] This application discloses a simulation engine data interaction method based on configurable reflection and method caching, which includes: Step 1: The simulation engine parses the structured configuration file to obtain the interaction mapping relationship list, the model definition list, and the time step. Each record in the interaction mapping relationship list includes the source model instance identifier, the target model instance identifier, the data field name, and the target model write method name. Each record in the model definition list includes the model instance identifier and the fully qualified name of the model class. Step 2: The simulation engine reads the model definition list, extracts all source model instance identifiers and target model instance identifiers appearing in the interaction mapping relationship list, and forms a set of model instance identifiers used in this simulation after deduplication. For each model instance identifier in this set, the fully qualified name of the corresponding model class is matched from the model definition list, the class is dynamically loaded using the Java reflection mechanism, and a model instance object is created. Based on all the model instance objects created by reflection, an instance mapping table is generated with the model instance identifier as the key and the model instance object reference as the value. Step 3: During the simulation initialization phase, the simulation engine reads the interaction mapping relationship list and parses each record one by one. For the current record, it first obtains the target model instance object corresponding to the target model instance identifier from the instance mapping table, and then parses the parameter type corresponding to the data field name. Based on the target model's write method name and parameter type, it obtains the write method Method object corresponding to the target model instance object through reflection. After calling the accessibility setting method of the Method object to disable access permission checks, it stores the Method object in the hash mapping table with the key: source model instance identifier: target model instance identifier: data field name. After traversal, the completed hash mapping table is delivered to the core scheduling engine module. Step 4: The core scheduling engine module reads the simulation time step and advances the simulation clock; within each simulation time tick, it traverses the interaction mapping relationship list, and for the current record, retrieves the source model instance object and the target model instance object from the instance mapping table; dynamically concatenates the data reading method name of the source model according to the naming convention based on the data field name, i.e., the getter method name, and retrieves the output data value of the source model through reflection; using the source model instance identifier: target model instance identifier: data field name as the key, it retrieves the corresponding Method object from the hash mapping table; and injects the output data into the target model instance through the invoke method of the Method object, completing the data interaction between models.

[0007] Furthermore, the dynamic creation of model instance objects via reflection includes: The class corresponding to the fully qualified name of the model class is loaded using Class.forName(). Class loading is only performed on models referenced in the interaction mapping list. Model instance objects are generated by calling the constructor of the loaded class. Model classes not referenced in the structured configuration file are not subject to class loading and instance creation.

[0008] Furthermore, the parameter type corresponding to the data field name in each record of the parsing interaction mapping relationship list includes any one of three implementation methods: Implementation method 1: Define the mapping relationship between data fields and types in the model class in advance, and retrieve the corresponding parameter type at runtime by looking up the table based on the data field name; Method 2: Add a parameterType field to the structured configuration file to explicitly indicate the parameter type corresponding to each interaction relationship; Implementation method 3: Traverse all write methods of the target model class, match the corresponding method according to the write method name of the target model, and extract the parameter type of the method.

[0009] Furthermore, the method name string corresponding to the target model's writing method is externally stored in the structured configuration file. During the simulation initialization phase, the target model instance object is obtained from the instance mapping table. Based on the target model's writing method name and the parsed parameter types, the corresponding Method object is pre-obtained through reflection. The Method object is stored in the hash mapping table with the source model instance identifier: target model instance identifier: data field name as the key. After obtaining the object corresponding to the target model's writing method through reflection, the object's setAccessible(true) method is called to disable the Java Virtual Machine access permission check.

[0010] Furthermore, the interactive operations of reading source model output data, retrieving model instances, and injecting reflections within each simulation time tick include: Retrieve the source model instance object corresponding to the source model instance identifier and the target model instance object corresponding to the target model instance identifier from the instance mapping table; Extract the data field names from the interaction mapping list, capitalize the first letter of the data field name and append the get prefix to generate the getter method name corresponding to the source model, and use reflection to call the getter method to obtain the output data value of the source model. Using a search key consisting of the source model instance identifier, the target model instance identifier, and the data field name, the corresponding Method object is matched from the hash map table. Call the invoke method of the Method object to reflectively inject the output data values ​​into the target model instance's write method.

[0011] Furthermore, when the source model instance identifier and the target model instance identifier of a single record in the interaction mapping list are the same, the following operations are performed: Retrieve the model instance object from the instance mapping table; Generate a getter method name by concatenating the data field names, and then retrieve the output data value of the model instance object through reflection. Retrieve the corresponding Method object from the hash map table; The `invoke` method reflects the output data values ​​into the target model's write method corresponding to the instance object, updating the model instance object's runtime parameters.

[0012] Furthermore, the objects stored in the hash map are Method objects, or the objects stored in the hash map are method handles of type java.lang.invoke.MethodHandle.

[0013] Furthermore, the structured configuration file includes the following fields: simulationName, tickInterval, interactions, and modelDefinitions. The simulationName field stores the simulation task name; the tickInterval field stores the simulation clock step; the interactions field is a list of interaction entries, used to store a list of interaction mapping relationships, where each interaction entry includes a source model instance identifier, a target model instance identifier, a data field name, and a target model write method name; the modelDefinitions field is a list of model definition entries, used to store the correspondence between model instance identifiers and fully qualified model class names. The structured configuration file can also add a parameterType field to explicitly label the parameter type corresponding to the data field.

[0014] Furthermore, the structured configuration file can be in JSON format, YAML format, or a binary serialization format defined using an interface definition language.

[0015] This application also discloses a simulation engine data interaction system based on configuration-based reflection and method caching, which implements the simulation engine data interaction method based on configuration-based reflection and method caching described above. It includes a configuration file parsing module, a reflective model factory module, a method handle cache pool module, and a core scheduling engine module. The configuration file parsing module is used to parse structured configuration files to obtain an interaction mapping relationship list, a model definition list, and a simulation time step. Each record in the interaction mapping relationship list includes a source model instance identifier, a target model instance identifier, a data field name, and a target model write method name. Each record in the model definition list includes a model instance identifier and a fully qualified name of the model class. The reflective model factory module is used to read the model definition list, extract the source model instance identifier and target model instance identifier from the interaction mapping relationship list, match them after deduplication to obtain the corresponding fully qualified name of the model class, and dynamically create model instance objects through reflection; based on all model instance objects created by reflection, an instance mapping table is generated with the model instance identifier as the key and the model instance object reference as the value. The method handle cache pool module is used to read the interaction mapping relationship list during the simulation initialization phase and parse each record one by one. For the current record, it obtains the target model instance object from the instance mapping table, parses the parameter type corresponding to the data field name, and obtains the corresponding Method object by reflection based on the method name and parameter type written in the target model. After calling the setAccessible method of the Method object to disable access permission checks, it stores the Method object in the hash mapping table with the source model instance identifier: target model instance identifier: data field name as the key. After traversal, the hash mapping table is handed over to the core scheduling engine module. The core scheduling engine module is used to read the time step to advance the simulation clock; within each simulation time tick, it traverses the interaction mapping relationship list; for the current record, it retrieves the source model instance object and the target model instance object from the instance mapping table; it dynamically concatenates the getter method name of the source model according to the naming convention based on the data field name, and retrieves the output data value of the source model through reflection; it matches the corresponding Method object from the hash mapping table using the source model instance identifier: target model instance identifier: data field name as the search key; and it injects the output data value into the target model's write method through the invoke method of the Method object, completing the data interaction between models.

[0016] Compared with the prior art, this application has the following beneficial technical effects: 1. Significantly reduced simulation compilation and deployment latency: By shifting model interface dependencies from compile time to runtime, complete decoupling is achieved between model source code. When the simulation interaction topology changes, only the text configuration file needs to be modified, eliminating the need to call the Java compiler to perform recompilation and bytecode verification processes. This eliminates compilation wait time caused by model modifications and improves the iterative verification efficiency of the simulation system.

[0017] 2. Significantly Optimized Memory Usage: Employing a lazy, on-demand loading strategy eliminates the preloading of invalid model classes. For ultra-large-scale simulation systems containing numerous potential model definitions, this solution significantly reduces the initial baseline of JVM heap memory usage, thereby increasing the number of concurrent simulation model instances that a single compute node can support and improving hardware resource utilization. Furthermore, the structured configuration file stores the interaction relationship list (interactions field) and the model definition list (modelDefinitions field) separately. This allows the simulation engine to first parse the interaction relationships to determine the set of model instance identifiers actually used in the simulation, and then load the corresponding model classes from the model definition list on demand based on this set. This provides data structure support for the lazy, on-demand instantiation strategy, further reducing unnecessary JVM heap memory usage.

[0018] 3. Ensuring Real-Time Performance of Simulation: By pre-caching the Method object (or the MethodHandle as an alternative implementation), the repetitive method lookup operation at runtime is optimized from the original time-consuming traversal search to a constant time retrieval using a hash table (O(1)). Simultaneously, by calling setAccessible(true) to disable Java access permission checks, the performance of reflection calls is brought close to that of native direct calls, ensuring the real-time requirements of simulation execution. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0020] Figure 1 This is a flowchart illustrating a simulation engine data interaction method based on configurable reflection and method caching, according to an embodiment of this application. Figure 2 This is a schematic diagram of the timing of single-cycle data interaction during the simulation process of an embodiment of this application; Figure 3 This is a block diagram of a simulation engine data interaction system based on configurable reflection and method caching, according to an embodiment of this application. Detailed Implementation

[0021] The present application will be further described in conjunction with the accompanying drawings and embodiments. The described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of the present application.

[0022] This application aims to address the following technical problems caused by hard-coded calls and static dependency injection mechanisms in the model data interaction process of existing simulation engines: repeated compilation and process restart overhead caused by interface coupling, which reduces the effective operating efficiency of the simulation system; unnecessary JVM heap memory occupation caused by full preloading, which limits the concurrency scale of single-node simulation models; and poor real-time performance of simulation cycle due to repeated reflection lookups during runtime.

[0023] See Figure 1 and Figure 2 This application provides a simulation engine data interaction method based on configurable reflection and method caching, including: S1: Configuration file parsing and interaction mapping relationship construction After the simulation engine starts, it reads structured configuration files such as JSON / YAML / ProtoBuf and parses them to obtain a list of interaction mapping relationships, a list of model definitions, and time steps. The interaction mapping relationship table consists of "source model instance identifier - target model instance identifier - data field name - target model write method name".

[0024] S2: Lazy on-demand instantiation of model instances Based on the fully qualified name of the model class actually referenced in the configuration, the model is dynamically loaded and instantiated via reflection using Class.forName(). Model classes not referenced in the configuration are not loaded or instantiated, saving JVM memory.

[0025] S3: Construction and caching of runtime method handle mapping tables During the initialization phase, all target write methods' Method / MethodHandle objects are obtained once via reflection, access permission checks are disabled, and a hash mapping table is built with source ID: target ID: field name as the key, so that the lookup is not repeated during runtime.

[0026] S4: Simulated beat-driven reflective data interaction Within each simulation time tick, the source model is triggered to generate output data, and the getter method is called to obtain the data; the method handle is quickly located in O(1) complexity through the cache table; the data is injected into the target model setter through invoke to complete the data interaction.

[0027] For ease of understanding, this embodiment uses a JSON-formatted configuration file as an example.

[0028] The implementation process of S1 includes: After the simulation engine process starts, the configuration file parsing module reads the predefined JSON configuration file and extracts the simulation name, cycle interval, model definition, and interaction relationship list. An example of the configuration file content is shown below; { "simulationName": "Radar Anti-Active Suppression Jamming Effectiveness Evaluation Simulation", "tickInterval": 50, "interactions": [ { "source": "Jammer_01", "target": "Radar_01", "dataField": "jammingPowerDensity", "targetMethod": "setExternalJammingSignal" }, { "source": "Radar_01", "target": "Radar_01", "dataField": "processedSNR", "targetMethod": "setDetectionThreshold" } ], "modelDefinitions": [ { "id": "Radar_01", "className": "com.emc.radar.PulseDopplerRadar" }, { "id": "Jammer_01", "className": "com.emc.jammer.BarrageNoiseJammer" } ] } The meanings of the fields in the configuration file are shown in Table 1.

[0029] Table 1. Meaning of fields in the configuration file

[0030] The implementation process of S2 includes: The reflective model factory module iterates through the aforementioned list of interaction definitions and model definitions, instantiating only the models used in the configuration; other models are not loaded. In this example, the fully qualified names of the classes actually used, "com.emc.radar.PulseDopplerRadar" and "com.emc.jammer.BarrageNoiseJammer", are extracted. The classes are dynamically loaded by executing `Class.forName(className)`, and instances are created by calling the constructors of the loaded classes, storing them in the instance mapping table with the identifiers "Radar_01" and "Jammer_01" as keys, respectively. For other model classes that exist in the classpath but are not referenced in the configuration file (such as "com.emc.radar.PhasedArrayRadar"), the engine does not perform any loading operations, thus saving JVM memory.

[0031] The implementation process of S3 includes: The method handle cache pool module iterates through the list of interaction definitions and performs the following key operations for each pair of interaction relationships: / / Pseudocode: Dynamically constructing a method handle cache table based on configuration files / / Step S3-1: Initialize the cache container Map<String, Method> methodCache = new HashMap<>(); / / Step S3-2: Traverse the list of interaction definitions obtained from the configuration file for (InteractionDef def : interactionDefList) { / / The def object contains the following fields parsed from the configuration file: / / def.sourceId Source model instance identifier / / def.targetId Target model instance identifier / / def.dataField interactive data field name / / def.targetMethod targetModel setMethodName / / Step S3-2-1: Obtain the target model instance object from the instance mapping table Object targetInstance = instanceMap.get(def.targetId); / / Step S3-2-2: Obtain the Class object of the target model instance Class<?> targetClass = targetInstance.getClass(); / / Step S3-2-3: Dynamically infer parameter types based on configured data field names In practice, the parameter type can be obtained in one of the following ways: / / Method A: Define the mapping relationship between data fields and types in the model class in advance / / Method B: Explicitly declare the parameterType field in the configuration file / / Method C: Iterate through all setter methods of the target class and match them according to naming conventions Class<?> paramType = resolveParameterType(def.targetId,def.dataField); / / Step S3-2-4: Dynamically obtain the Method object using reflection (the method name and parameter types are read from the configuration). Method setterMethod = targetClass.getMethod(def.targetMethod,paramType); / / Step S3-2-5: Disable access permission checks to improve reflection call performance setterMethod.setAccessible(true); / / Step S3-2-6: Construct cache keys and store them in a hash mapping table String cacheKey = def.sourceId + ":" + def.targetId + ":" +def.dataField; methodCache.put(cacheKey, setterMethod); } / / Step S3-3: Deliver the completed cache table reference to the core scheduling engine coreScheduler.setMethodCache(methodCache); The method handle cache pool module ultimately constructs a global HashMap.<String,Method> The hash map is then used to cache the table, and a reference to this cache table is delivered to the core scheduling engine module.

[0032] The implementation process of S4 includes: The core scheduling engine module reads the simulation time step to advance the simulation cycle. Within each simulation time step, the engine traverses the interaction definition list parsed from the configuration file, dynamically executing data acquisition and reflection injection operations for each interaction relationship. In this embodiment, each simulation time step is divided into two stages: the first stage is the data interaction stage, which traverses the interaction mapping relationship list and executes data transfer for all interaction relationships; the second stage is the business execution stage, which traverses all model instances in the instance mapping table, calls their business execution methods to update their internal states, and prepares output data for the data interaction of the next stage.

[0033] The pseudocode for the data interaction phase is as follows: / / Phase 1: Data Interaction Phase / / Get the list of interaction definitions parsed from the configuration file List <interactiondef>interactionDefList = configParser.getInteractionDefList(); / / Traverse all interaction relationships and perform data transfer for (InteractionDef def : interactionDefList) { / / Get source model instance and target model instance Object sourceInstance = instanceMap.get(def.getSourceId()); Object targetInstance = instanceMap.get(def.getTargetId()); / / Dynamically concatenate the getter method names of the source model and call them to retrieve data values. String getterMethodName = "get" + capitalize(def.getDataField()); Method getterMethod = sourceInstance.getClass().getMethod(getterMethodName); Object dataValue = getterMethod.invoke(sourceInstance); / / Construct a cache key and retrieve the corresponding setter method handle from the cache table / / Note: setterMethod has already called setAccessible(true) in the S3 phase. / / Disable access permission checks String cacheKey = def.getSourceId() + ":" +def.getTargetId() + ":" + def.getDataField(); Method setterMethod = methodCache.get(cacheKey); / / Perform reflection call to complete data writing setterMethod.invoke(targetInstance, dataValue); } / / Utility methods: First letter capitalized private String capitalize(String str) { return Character.toUpperCase(str.charAt(0)) + str.substring(1); } The pseudocode for the business execution phase is as follows: / / Phase Two: Business Execution Phase for (Object modelInstance : instanceMap.values()) { Method executeMethod = modelInstance.getClass().getMethod("execute"); executeMethod.invoke(modelInstance); } The timing flow of S4 is as follows Figure 2 As shown. Taking the configuration file provided by S1 as an example, the execution flow of S4 is as follows: a) Upon entering the data interaction phase, the engine traverses the list of interaction mapping relationships; b) For the first interaction relationship (Jammer_01→Radar_01), the engine retrieves the Jammer_01 instance and the Radar_01 instance from the instance mapping table, and calls the getter method of Jammer_01 (such as getJammingPowerDensity()) to obtain the output data value. c) The engine constructs the cache key "Jammer_01:Radar_01:jammingPowerDensity" and quickly retrieves the corresponding Method object from the hash map table in O(1) time complexity; d) The engine executes method.invoke(instanceMap.get("Radar_01"),value) to complete the dynamic writing of data from the jammer model to the radar model; e) For the second interaction relationship (the source model instance identifier and the target model instance identifier are the same, both being Radar_01), the engine obtains the Radar_01 instance from the instance mapping table, calls its getter method (such as getProcessedSNR()) to obtain the output data value value; the engine constructs the cache key "Radar_01:Radar_01:processedSNR", and quickly obtains the corresponding Method object (i.e., the handle of the setDetectionThreshold method) from the hash mapping table in O(1) time complexity; the engine executes method.invoke(instanceMap.get("Radar_01"),value), completes the self-feedback data writing inside the radar model, and updates the detection threshold parameters; f) After the data interaction phase is completed, the business execution phase begins. The engine traverses all model instances in the instance mapping table and calls Jammer_01.execute() and Radar_01.execute() in sequence. Each model updates its internal state based on the newly injected data to prepare for the output data in the next cycle.

[0034] Description of Alternative Implementation Methods Although the above embodiments are described using JSON format and the standard Java reflection API (java.lang.reflect.Method), those skilled in the art will understand that, based on the concept of this application, the following equivalent or alternative methods can also be used, all of which fall within the protection scope of this application: 1. The configuration file format can be replaced with any structured description language that can describe the relationship between key-value pairs and lists, such as YAML or Protocol Buffers text format; 2. Java reflection calls can be replaced by the java.lang.invoke.MethodHandle mechanism to achieve better JIT just-in-time compilation inlining optimization results; 3. Parameter type inference can avoid the runtime type lookup overhead by pre-declaring the parameterType field (such as "java.lang.Double") in the configuration file.

[0035] Also see Figure 3 This application provides a simulation engine data interaction system based on configurable reflection and method caching, deployed in a computing device equipped with a Java Virtual Machine, comprising: 1. Configuration file parsing module: Reads and parses the configuration file to generate a list of interaction mapping relationships; 2. Reflective Model Factory Module: Creates model instances based on configuration using reflection, and maintains a mapping table between instance identifiers and object references; 3. Method handle cache pool module: pre-acquires and caches method handles to avoid repeated reflection lookups at runtime; 4. Core scheduling engine module: drives the simulation clock, drives the execution of each model, and completes data reflection injection.

[0036] Specifically, the configuration file parsing module is responsible for reading and parsing the structured interaction configuration file, converting its contents into a list of InteractionDefinition data objects in memory. Each InteractionDefinition object contains at least four attributes: source model identifier, target model identifier, interaction data field name, and target model write method name. Specifically, the reflective model factory module is responsible for dynamically creating model instances using Java reflection based on the fully qualified class name string obtained from the configuration file, and maintaining a mapping table of "model instance identifier - model instance object reference". Specifically, the method handle cache pool module is used to read the interaction mapping relationship list during simulation initialization, and parse each record one by one; for the current record, it obtains the target model instance object from the instance mapping table, parses the parameter type corresponding to the data field name, and obtains the corresponding Method object by reflection based on the method name and parameter type written in the target model; after calling the setAccessible method of the Method object to disable access permission checks, it stores the Method object in the hash mapping table with the source model instance identifier: target model instance identifier: data field name as the key; after traversal, the hash mapping table is handed over to the core scheduling engine module. Specifically, the core scheduling engine module acts as the driver for simulation execution. It is responsible for advancing the simulation clock according to a preset step size, triggering source model calculations at each tick, calling getters to obtain data, retrieving setters from the cache and injecting them via reflection to complete data interaction.

[0037] Interaction relationship definition based on configuration file: The data flow between simulation models and the specific set method name called are externalized in the structured configuration file in the form of strings, which realizes the complete decoupling of model code and interaction topology.

[0038] Runtime reflection method handle pre-caching: The method name string is converted to a Method object and stored in a hash map table in one go during the initialization phase, overcoming the performance bottleneck of conventional reflection calls under high-frequency simulation.

[0039] Lazy loading of model classes: Class.forName() is only executed on models that participate in the interaction, controlling the baseline of memory usage at the JVM class loading level.

[0040] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.< / interactiondef>

Claims

1. A simulation engine data interaction method based on configuration-based reflection and method caching, characterized in that, include: Step 1: The simulation engine parses the structured configuration file to obtain the interaction mapping relationship list, the model definition list, and the time step. Each record in the interaction mapping relationship list includes the source model instance identifier, the target model instance identifier, the data field name, and the target model write method name. Each record in the model definition list includes the model instance identifier and the fully qualified name of the model class. Step 2: The simulation engine reads the model definition list, extracts all source model instance identifiers and target model instance identifiers appearing in the interaction mapping relationship list, and forms a set of model instance identifiers used in this simulation after deduplication. For each model instance identifier in this set, the fully qualified name of the corresponding model class is matched from the model definition list, the class is dynamically loaded using the Java reflection mechanism, and a model instance object is created. Based on all the model instance objects created by reflection, an instance mapping table is generated with the model instance identifier as the key and the model instance object reference as the value. Step 3: During the simulation initialization phase, the simulation engine reads the interaction mapping relationship list and parses each record one by one. For the current record, it first obtains the target model instance object corresponding to the target model instance identifier from the instance mapping table, and then parses the parameter type corresponding to the data field name. Based on the target model's write method name and parameter type, it obtains the write method Method object corresponding to the target model instance object through reflection. After calling the accessibility setting method of the Method object to disable access permission checks, it stores the Method object in the hash mapping table with the key: source model instance identifier: target model instance identifier: data field name. After traversal, the completed hash mapping table is delivered to the core scheduling engine module. Step 4: The core scheduling engine module reads the simulation time step and advances the simulation clock; within each simulation time tick, it traverses the interaction mapping relationship list, and for the current record, retrieves the source model instance object and the target model instance object from the instance mapping table; dynamically concatenates the data reading method name of the source model according to the naming convention based on the data field name, i.e., the getter method name, and retrieves the output data value of the source model through reflection; using the source model instance identifier: target model instance identifier: data field name as the key, it retrieves the corresponding Method object from the hash mapping table; and injects the output data into the target model instance through the invoke method of the Method object, completing the data interaction between models.

2. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The method of dynamically creating model instance objects through reflection includes: The class corresponding to the fully qualified name of the model class is loaded using Class.forName(). Class loading is only performed on models referenced in the interaction mapping list. Model instance objects are generated by calling the constructor of the loaded class. Model classes not referenced in the structured configuration file are not subject to class loading and instance creation.

3. The simulation engine data interaction method based on configurable reflection and method caching according to claim 1, characterized in that, The parameter type corresponding to the data field name in each record of the parsing interaction mapping relationship list includes any one of three implementation methods: Implementation method 1: Define the mapping relationship between data fields and types in the model class in advance, and retrieve the corresponding parameter type at runtime by looking up the table based on the data field name; Method 2: Add a parameterType field to the structured configuration file to explicitly indicate the parameter type corresponding to each interaction relationship; Implementation method 3: Traverse all write methods of the target model class, match the corresponding method according to the write method name of the target model, and extract the parameter type of the method.

4. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The method name string corresponding to the method written to the target model is stored externally in the structured configuration file; During the simulation initialization phase, the target model instance object is obtained from the instance mapping table. Based on the method name written in the target model and the parsed parameter types, the corresponding Method object is pre-obtained through reflection. The Method object is stored in the hash mapping table with the source model instance identifier: target model instance identifier: data field name as the key. After obtaining the object corresponding to the method written in the target model through reflection, the setAccessible(true) method of the object is called to disable the Java Virtual Machine access permission check.

5. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The interactive operations of reading source model output data, retrieving model instances, and injecting reflections are completed within each simulation time tick, including: Retrieve the source model instance object corresponding to the source model instance identifier and the target model instance object corresponding to the target model instance identifier from the instance mapping table; Extract the data field names from the interaction mapping list, capitalize the first letter of the data field name and append the get prefix to generate the getter method name corresponding to the source model, and use reflection to call the getter method to obtain the output data value of the source model. Using a search key consisting of the source model instance identifier, the target model instance identifier, and the data field name, the corresponding Method object is matched from the hash map table. Call the invoke method of the Method object to reflectively inject the output data values ​​into the target model instance's write method.

6. The simulation engine data interaction method based on configurable reflection and method caching according to claim 5, characterized in that, When the source model instance identifier and the target model instance identifier of a single record in the interaction mapping list are the same, perform the following operations: Retrieve the model instance object from the instance mapping table; Generate a getter method name by concatenating the data field names, and then use reflection to call the model instance object to obtain the output data value. Retrieve the corresponding Method object from the hash map table; The `invoke` method reflects the output data values ​​into the target model's write method corresponding to the instance object, updating the model instance object's runtime parameters.

7. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The objects stored in the hash map are Method objects, or the objects stored in the hash map are method handles, and the method handles are of type java.lang.invoke.MethodHandle.

8. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The structured configuration file includes the following fields: simulationName, tickInterval, interactions, and modelDefinitions. The simulationName field stores the simulation task name; the tickInterval field stores the simulation clock step; the interactions field is a list of interaction entries, storing a list of interaction mapping relationships, where each interaction entry includes a source model instance identifier, a target model instance identifier, a data field name, and a target model write method name; the modelDefinitions field is a list of model definition entries, storing the correspondence between model instance identifiers and fully qualified model class names. The structured configuration file can also add a parameterType field to explicitly label the parameter type corresponding to the data field.

9. The simulation engine data interaction method based on configuration-based reflection and method caching according to claim 1, characterized in that, The structured configuration file can be in JSON, YAML, or a binary serialization format defined using an interface definition language.

10. A simulation engine data interaction system based on configurable reflection and method caching, implementing the simulation engine data interaction method based on configurable reflection and method caching as described in any one of claims 1-9, characterized in that, It includes a configuration file parsing module, a reflective model factory module, a method handle cache pool module, and a core scheduling engine module; The configuration file parsing module is used to parse structured configuration files to obtain an interaction mapping relationship list, a model definition list, and a simulation time step. Each record in the interaction mapping relationship list includes a source model instance identifier, a target model instance identifier, a data field name, and a target model write method name. Each record in the model definition list includes a model instance identifier and a fully qualified name of the model class. The reflective model factory module is used to read the model definition list, extract the source model instance identifier and target model instance identifier from the interaction mapping relationship list, match them after deduplication to obtain the corresponding fully qualified name of the model class, and dynamically create model instance objects through reflection; based on all model instance objects created by reflection, an instance mapping table is generated with the model instance identifier as the key and the model instance object reference as the value. The method handle cache pool module is used to read the interaction mapping relationship list during the simulation initialization phase and parse each record one by one. For the current record, it obtains the target model instance object from the instance mapping table, parses the parameter type corresponding to the data field name, and obtains the corresponding Method object by reflection based on the method name and parameter type written in the target model. After calling the setAccessible method of the Method object to disable access permission checks, it stores the Method object in the hash mapping table with the source model instance identifier: target model instance identifier: data field name as the key. After traversal, the hash mapping table is handed over to the core scheduling engine module. The core scheduling engine module is used to read the time step to advance the simulation clock; within each simulation time tick, it traverses the interaction mapping relationship list; for the current record, it retrieves the source model instance object and the target model instance object from the instance mapping table; it dynamically concatenates the getter method name of the source model according to the naming convention based on the data field name, and retrieves the output data value of the source model through reflection; it matches the corresponding Method object from the hash mapping table using the source model instance identifier: target model instance identifier: data field name as the search key; and it injects the output data value into the target model's write method through the invoke method of the Method object, completing the data interaction between models.

Images