R中使用lapply时如何内存高效修改上层变量或计数器

在R中编写函数时，若在函数内初始化变量后尝试在lapply的匿名函数内部通过<-修改该变量，由于<-仅在当前函数作用域内赋值，修改后的值无法在不同迭代轮次间传递，会得到不符合预期的结果，错误实现代码如下：

f <- function() {
    a <- 1
    lapply(seq_len(1000000), function(i) {
        print(paste0('a:', a))
        b <- a + 1
        a <- b
        print(paste0('a:', a))
        print(paste0('b:', b))
    })
}

f()
# 运行输出（节选）
# [1] "a:1"
# [1] "a:2"
# [1] "b:2"
# [1] "a:1"
# [1] "a:2"
# [1] "b:2"
...

使用超赋值运算符<<-虽然可以实现跨作用域赋值、让值在迭代间传递，但百万级迭代场景下<<-的作用域逐层查找逻辑会带来极高的时间开销，实现代码如下：

f2 <- function() {
    a <- 1
    lapply(seq_len(1000000), function(i) {
        print(paste0('a:', a))
        b <- a + 1
        a <<- b
        print(paste0('a:', a))
        print(paste0('b:', b))
    })
}

f2()
# 运行输出（节选）
# [1] "a:1"
# [1] "a:2"
# [1] "b:2"
# [1] "a:2"
# [1] "a:3"
# [1] "b:3"
...

针对该场景，需要找到无变量复制、内存效率高的变量修改方案。

R中*环境（environment）*是内核原生支持的引用语义对象，对环境内变量的所有修改都是原地操作，不会触发对象复制，也不需要每次迭代做作用域链遍历，性能远高于<<-，且零额外依赖，是这类需求的首选方案。
实现代码如下：

f_env <- function() {
  # 初始化独立环境存储可变状态，指定空父环境避免多余的作用域查找
  mutable_state <- new.env(parent = emptyenv())
  mutable_state$a <- 1
  lapply(seq_len(1000000), function(i) {
    print(paste0('a:', mutable_state$a))
    # 直接修改环境内的变量，全程无复制、无作用域遍历开销
    new_val <- mutable_state$a + 1
    mutable_state$a <- new_val
    print(paste0('a:', mutable_state$a))
    print(paste0('b:', new_val))
  })
}

该方案的优势：

• 所有修改为原地操作，不会触发R的对象复制机制，内存开销极低
• 直接通过固定环境位置读取、修改变量，没有<<-的逐层作用域查找开销，百万级迭代下性能差距可达数十倍
• 可变状态全部封装在函数内部的独立环境中，不会污染全局环境，也不会出现隐式作用域bug
• 无需依赖任何第三方包，R原生支持，兼容性最好

如果你的数据处理流程已经重度依赖data.table，也可以利用data.table的引用语义实现原地修改，效果和环境方案接近，适合和现有data.table流程结合：

library(data.table)
f_dt <- function() {
  # 初始化单值data.table存储状态
  state <- data.table(a = 1)
  lapply(seq_len(1000000), function(i) {
    print(paste0('a:', state$a))
    # := 是data.table的原地赋值运算符，无复制开销
    new_val <- state$a + 1
    state[, a := new_val]
    print(paste0('a:', state$a))
    print(paste0('b:', new_val))
  })
}

注意如果只是为了存储单个可变状态，环境方案的内存和性能开销比data.table更低，不需要额外引入第三方依赖。

• 不建议在迭代逻辑中使用<<-传递状态，除了性能问题外，<<-如果在当前作用域链上找不到目标变量，会直接在全局环境创建变量，容易引发难以排查的变量污染问题
• 如果迭代逻辑可以改写为向量化实现，优先选择向量化方案，性能会比任何lapply循环方案更高；但如果必须保留逐次迭代的逻辑（比如每轮迭代有复杂的副作用操作），环境方案是最优选择。

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