Go Gonum quad 怎样限制函数求值并发量

如果你使用 gonum.org/v1/gonum/integrate/quad 做固定节点数值积分，想限制函数回调同时执行的数量，直接设置 quad.Fixed 的最后一个参数 concurrent 即可。例如传入 4，表示函数 f 最多同时有 4 次求值。传入小于等于 0 的值则按串行方式求值。

官方地址：https://pkg.go.dev/gonum.org/v1/gonum/integrate/quad

要限制的是同一时刻活跃的 f(x) 调用，不是把采样点数量 n 改小。并发回调如果访问共享状态，还要自己保证回调安全。

先分清 n 和 concurrent

quad.Fixed 的签名是 Fixed(f, min, max, n, rule, concurrent)。其中 n 是固定求积规则使用的采样点数量，影响积分近似的计算规模；concurrent 是函数求值的并发上限，影响同一时刻会有多少次 f(x) 在执行。

因此，n=1000、concurrent=4 的含义是仍然处理 1000 个采样点，但最多让 4 个回调同时运行。把 n 改成 4 并不能表达“最多 4 个并发”，反而会改变数值积分的采样密度。

用 concurrent 参数设置硬上限

下面的写法把并发上限固定为 4。这里把耗时操作放在回调里只是为了展示调度边界，实际项目应根据 CPU、外部服务额度和回调是否可并行来选择数值。

package main

import (
	"fmt"
	"math"

	"gonum.org/v1/gonum/integrate/quad"
)

func main() {
	// 回调只依赖输入 x，适合被有限数量的 goroutine 同时调用。
	f := func(x float64) float64 {
		return math.Exp(-x * x)
	}

	// n 是采样点数量，4 是 f 的最大同时求值数量。
	result := quad.Fixed(f, 0, 1, 1000, nil, 4)
	fmt.Printf("integral=%.8f\\n", result)
}

这个参数只约束 Gonum 在积分过程中同时调用 f 的数量。它不是全局 goroutine 限制，也不会限制程序中其它任务创建的 goroutine；如果回调内部又启动了额外并发，需要在那一层单独管理。

把并发风险当成回调边界处理

当 concurrent>0 时，f 可能被同时调用。最安全的回调通常是只读输入、只使用局部变量并返回结果；如果它写入缓存、统计计数器或复用不可并发访问的对象，就要加同步保护，或者把 concurrent 设为 0。

例如，回调需要更新一个共享计数器时，互斥锁应该只保护共享状态，不要把整个积分过程包在一把外层大锁里，否则并发上限虽然设置了，实际执行仍会退化为串行。

package main

import (
	"math"
	"sync"

	"gonum.org/v1/gonum/integrate/quad"
)

func integrateWithSafeCounter() float64 {
	var mu sync.Mutex
	called := 0

	f := func(x float64) float64 {
		// 只在写共享计数器时加锁，让数值计算仍能并行执行。
		mu.Lock()
		called++
		mu.Unlock()

		// 局部计算不依赖共享可变对象，可以安全地并发求值。
		return math.Sin(x) * math.Exp(-x)
	}

	// concurrent=4 限制回调同时执行数量；锁保护的是 called，而不是整个积分。
	return quad.Fixed(f, 0, 10, 800, nil, 4)
}

如果共享对象本身不能安全地拆成小段临界区，例如某个第三方客户端要求单线程使用，那么更稳妥的做法是让回调只负责计算，或者直接传入 0 使用串行求值。不要把 concurrent=4 理解成“Gonum 会替你修复回调的线程安全问题”。

把并发上限和外部资源额度分开

如果 f 内部访问数据库、HTTP 服务或文件系统，concurrent 可以作为这一轮积分的第一道上限，但它不一定等于外部资源允许的最大并发。多个积分任务同时运行时，四个并发乘以任务数量仍可能压垮下游。

工程上可以把回调拆成两层：外层由 quad.Fixed 限制积分求值的并发，内层对共享客户端、连接池或服务配额使用独立的信号量或连接池配置。这样能清楚区分“数值积分调度”与“外部资源保护”，也方便记录每一层的容量。

// 这个片段展示配置意图：两个上限分别服务于两种资源。
const (
	quadConcurrent   = 4  // 单次积分最多同时执行 4 个回调
	serviceConcurrent = 8 // 共享服务最多允许 8 个请求同时进入
)

用轻量计数记录实际边界

为了排查配置是否被误读，可以在回调入口和出口维护活跃数与最大值。计数器只用于观测，不要让观测逻辑改变积分结果；退出路径用 defer 归还计数，避免异常返回时留下错误的活跃数。

var active atomic.Int32
var maxActive atomic.Int32

f := func(x float64) float64 {
	// 进入回调时递增，并用 CAS 记录观察到的最大活跃数。
	current := active.Add(1)
	for {
		old := maxActive.Load()
		if current <= old || maxActive.CompareAndSwap(old, current) {
			break
		}
	}
	defer active.Add(-1) // 无论回调如何返回，都释放本次活跃计数

	return math.Cos(x)
}

在这种记录方式下，maxActive 反映的是回调实际观察到的峰值。它不等于 CPU 使用率，也不能说明积分误差；它只适合核对并发边界和发现是否存在额外的下游并发。

常见问题

concurrent 设为 0 是完全不执行函数吗？

不是。根据 quad.Fixed 的参数语义，小于等于 0 表示串行求值，函数仍会按求积规则被调用。

concurrent 越大，积分结果会更准确吗？

不会。并发参数主要改变调度方式；结果精度更直接受采样点数量、求积规则和函数本身影响。并发过大还可能增加上下文切换或下游资源压力。

能否只靠 concurrent 保护 map 或第三方客户端？

不能。它只限制同时进入回调的数量，不会替回调内部的共享对象加锁。需要根据对象的并发约束使用互斥、独立实例或串行求值。

速查清单

• 先确认 n 是采样点数量，不要用它代替并发配置。
• 需要限制回调同时执行数量时，把最后一个参数设为明确的正整数。
• 回调只读、局部计算优先；访问共享可变状态时缩小锁范围或改为串行。
• 数据库、HTTP 服务和连接池的额度要单独设计，不能只看 quad.Fixed 的并发值。
• 用活跃计数记录峰值，核对它是否符合容量预期，但不要把它当成精度指标。