Java 11如何在运行时获取作用域内变量并按名称取对应实例？

Java 没有提供原生API支持按名称直接获取方法内声明的局部变量，你最初想的「获取当前作用域所有变量再按名匹配」的思路，在常规生产环境下走不通——方法局部变量存储在栈帧的局部变量表中，默认运行时不会保留可直接遍历查询的名称映射，就算通过调试参数、字节码工具强行获取，稳定性和性能都无法满足生产要求。

方案1：显式维护可访问变量上下文（生产环境首选） #

这是最稳妥、兼容性最好的实现方式：提前把所有允许被数据库配置选中的变量，手动注册到一个上下文Map中，后续直接按配置的变量名从上下文取值即可。
改造后的示例代码：

public void testService() {
    String keyValuePairTakenFromDB = "{\"varName\":\"fileDTO\"}";
    ObjectMapper mapper = new ObjectMapper();
    
    // 1. 初始化变量上下文，存放所有支持动态选择的对象
    Map<String, Object> variableContext = new HashMap<>();
    // 2. 初始化业务对象，注册到上下文
    FileDTO fileDTO = new FileDTO();
    fileDTO.setToken("token12345");
    variableContext.put("fileDTO", fileDTO);
    // 后续如果有其他需要支持动态选择的对象，按同样方式注册即可

    try {
        JsonNode jsonNode = mapper.readTree(keyValuePairTakenFromDB);
        String variableKey = jsonNode.get("varName").asText();
        HashMap<String, Object> request = new HashMap<>();
        
        // 3. 做合法性校验后，从上下文取对象放入请求Map
        if (!variableContext.containsKey(variableKey)) {
            throw new IllegalArgumentException("配置指定的变量不存在：" + variableKey);
        }
        request.put(variableKey, variableContext.get(variableKey));
        // 最终request的结果等价于request.put("fileDTO", fileDTO)，符合预期
    } catch (JsonProcessingException jsonProcessingException) {
        jsonProcessingException.printStackTrace();
    }
}

• 优点：无黑魔法、性能高、全JDK版本兼容，还可以自主控制变量的暴露范围，避免敏感对象被误引用。
• 缺点：需要手动注册允许动态选择的变量，增加少量编码工作。

方案2：反射获取类成员变量（仅适用于非局部变量场景） #

如果你要获取的不是方法内声明的局部变量，而是当前类的成员字段（类属性），可以直接用Java反射API按名称取值，不需要额外维护上下文：

// 假设fileDTO是当前类的成员变量，而非testService方法内声明的局部变量
try {
    Field targetField = this.getClass().getDeclaredField(variableKey);
    targetField.setAccessible(true);
    Object targetInstance = targetField.get(this);
    request.put(variableKey, targetInstance);
} catch (NoSuchFieldException | IllegalAccessException e) {
    // 处理字段不存在、无访问权限的异常
    e.printStackTrace();
}

注意：这个方式完全无法获取方法内部声明的局部变量，仅能作用于类层级的字段。

方案3：字节码/调试API获取（生产环境禁用） #

如果是非生产的调试类场景，可以通过JDI（Java调试接口）、ASM/ByteBuddy等字节码工具插桩读取局部变量表，强行按名称获取局部变量。但这个方案存在严重缺陷：

• 需要JVM启动时开启调试参数，会带来性能损耗和安全风险
• 编译优化（比如JIT编译、变量消除）可能导致局部变量表信息丢失、错乱，逻辑稳定性极差
• 实现复杂度极高，维护成本远大于收益
  仅适合做本地调试工具，绝对不能用到线上业务逻辑中。

内容的提问来源于stack exchange，提问作者Amila OS