Go内存优化与垃圾收集

Go提供了自动化的内存管理机制，但在某些情况下需要更精细的微调从而避免发生OOM错误。本文介绍了如何通过微调GOGC和GOMEMLIMIT在性能和内存效率之间取得平衡，并尽量避免OOM的产生。原文: Memory Optimization and Garbage Collector Management in Go

alt

本文将讨论Go的垃圾收集器、应用程序内存优化以及如何防止OOM(Out-Of-Memory)错误。

Go中的堆(Heap)栈(Stack)

我不会详细介绍垃圾收集器如何工作，已经有很多关于这个主题的文章和官方文档(比如A Guide to the Go Garbage Collector[1]和源码[2])。但是，我会提到一些有助于理解本文主题的基本概念。

你可能已经知道，Go的数据可以存储在两个主要的内存存储中: 栈(stack)和堆(heap)。

alt

通常，栈存储的数据的大小和使用时间可以由Go编译器预测，包括函数局部变量、函数参数、返回值等。

栈是自动管理的，遵循后进先出(LIFO)原则。当调用函数时，所有相关数据都放在栈的顶部，函数结束时，这些数据将从栈中删除。栈不需要复杂的垃圾收集机制，其内存管理开销最小，在栈中检索和存储数据的过程非常快。

然而，并不是所有数据都可以存储在栈中。在执行过程中动态更改的数据或需要在函数范围之外访问的数据不能放在栈上，因为编译器无法预测其使用情况，这种数据应该存储在堆中。

与栈不同，从堆中检索数据并对其进行管理的成本更高。

栈里放什么，堆里放什么?

正如前面提到的，栈用于具有可预测大小和寿命的值，例如:

  • 在函数内部声明的局部变量，例如基本数据类型变量(例如数字和布尔值)。
  • 函数参数。
  • 函数返回后不再被引用的返回值。

Go编译器在决定将数据放在栈中还是堆中时会考虑各种细微差别。

例如，预分配大小为64 KB的数据将存储在栈中，而大于64 KB的数据将存储在堆中。这同样适用于数组，如果数组超过10 MB，将存储在堆中。

alt

可以使用逃逸分析(escape analysis)来确定特定变量的存储位置。

例如，可以通过命令行编译参数-gcflags=-m来分析应用程序:

go build -gcflags=-m main.go

如果使用-gcflags=-m参数编译下面的main.go:

package main

func main() {
  var arrayBefore10Mb [1310720]int
  arrayBefore10Mb[0] = 1

  var arrayAfter10Mb [1310721]int
  arrayAfter10Mb[0] = 1

  sliceBefore64 := make([]int, 8192)
  sliceOver64 := make([]int, 8193)
  sliceOver64[0] = sliceBefore64[0]
}

结果是:

# command-line-arguments
./main.go:3:6: can inline main
./main.go:7:6: moved to heap: arrayAfter10Mb
./main.go:10:23: make([]int, 8192) does not escape
./main.go:11:21: make([]int, 8193) escapes to heap

可以看到arrayAfter10Mb数组被移动到堆中，因为大小超过了10MB，而arrayBefore10Mb仍然留在栈中(对于int变量，10MB等于10 * 1024 * 1024 / 8 = 1310720个元素)。

此外，sliceBefore64没有存储在堆中，因为它的大小小于64KB，而sliceOver64被存储在堆中(对于int变量，64KB等于64 * 1024 / 8 = 8192个元素)。

要了解更多关于在堆中分配的位置和内容，可以参考malloc.go源码[3]。

因此，使用堆的一种方法是尽量避免用它！但是，如果数据已经落在堆中了呢？

与栈不同，堆的大小是无限的，并且不断增长。堆存储动态创建的对象，如结构体、分片和映射，以及由于其限制而无法放入栈中的大内存块。

在堆中重用内存并防止其完全阻塞的唯一工具是垃圾收集器。

浅谈垃圾收集器的工作原理

垃圾收集器(GC)是一种专门用于识别和释放动态分配内存的系统。

Go使用基于跟踪和标记和扫描算法的垃圾收集算法。在标记阶段，垃圾收集器将应用程序正在使用的数据标记为活跃堆。然后，在清理阶段，GC遍历所有未标记为活跃的内存并复用。

垃圾收集器不是免费工作的，需要消耗两个重要的系统资源: CPU时间和物理内存。

垃圾收集器中的内存由以下部分组成:

  • 活跃堆内存(在前一个垃圾收集周期中标记为"活跃"的内存)
  • 新的堆内存(尚未被垃圾收集器分析的堆内存)
  • 存储元数据的内存，与前两个实体相比，这些元数据通常微不足道。

垃圾收集器所消耗的CPU时间与其工作细节有关。有一种称为"stop-the-world"的垃圾收集器实现，它在垃圾收集期间完全停止程序执行，导致CPU时间被花在非生产性工作上。

在Go里，垃圾收集器并不是完全"stop-the-world"，而是与应用程序并行执行其大部分工作(例如标记堆)。

但是，垃圾收集器的操作仍然有一些限制，并且会在一个周期内多次完全停止工作代码的执行，想要了解更多可以阅读源码[4]。

alt
如何管理垃圾收集器

在Go中可以通过某些参数管理垃圾收集器: GOGC环境变量或runtime/debug包中的等效函数SetGCPercent。

GOGC参数确定将触发垃圾收集的新未分配堆内存相对于活跃内存的百分比。

GOGC的默认值是100，意味着当新内存达到活跃堆内存的100%时将触发垃圾收集。

当新堆占用活跃堆的100%时，将运行垃圾收集器。
当新堆占用活跃堆的100%时，将运行垃圾收集器。

我们以示例程序为例，通过go tool trace跟踪堆大小的变化，我们用Go 1.20.1版本来运行程序。

在本例中，performMemoryIntensiveTask函数使用了在堆中分配的大量内存。这个函数启动一个队列大小为NumWorker的工作池，任务数量等于NumTasks。

package main

import (
 "fmt"
 "os"
 "runtime/debug"
 "runtime/trace"
 "sync"
)

const (
 NumWorkers    = 4     // Number of workers.
 NumTasks      = 500   // Number of tasks.
 MemoryIntense = 10000 // Size of memory-intensive task (number of elements).
)

func main() {
 // Write to the trace file.
 f, _ := os.Create("trace.out")
 trace.Start(f)
 defer trace.Stop()

 // Set the target percentage for the garbage collector. Default is 100%.
 debug.SetGCPercent(100)

 // Task queue and result queue.
 taskQueue := make(chan int, NumTasks)
 resultQueue := make(chan int, NumTasks)

 // Start workers.
 var wg sync.WaitGroup
 wg.Add(NumWorkers)
 for i := 0; i < NumWorkers; i++ {
  go worker(taskQueue, resultQueue, &wg)
 }

 // Send tasks to the queue.
 for i := 0; i < NumTasks; i++ {
  taskQueue <- i
 }
 close(taskQueue)

 // Retrieve results from the queue.
 go func() {
  wg.Wait()
  close(resultQueue)
 }()

 // Process the results.
 for result := range resultQueue {
  fmt.Println("Result:", result)
 }

 fmt.Println("Done!")
}

// Worker function.
func worker(tasks <-chan int, results chan<- int, wg *sync.WaitGroup) {
 defer wg.Done()

 for task := range tasks {
  result := performMemoryIntensiveTask(task)
  results <- result
 }
}

// performMemoryIntensiveTask is a memory-intensive function.
func performMemoryIntensiveTask(task int) int {
 // Create a large-sized slice.
 data := make([]int, MemoryIntense)
 for i := 0; i < MemoryIntense; i++ {
  data[i] = i + task
 }

 // Latency imitation.
 time.Sleep(10 * time.Millisecond)

 // Calculate the result.
 result := 0
 for _, value := range data {
  result += value
 }
 return result
}

跟踪程序执行的结果被写入文件trace.out:

// Writing to the trace file.
f, _ := os.Create("trace.out")
trace.Start(f)
defer trace.Stop()

通过go tool trace，可以观察堆大小的变化，并分析程序中垃圾收集器的行为。

请注意，go tool trace的精确细节和功能可能因go版本不同而有所差异，因此建议参考官方文档，以获取有关其在特定go版本中使用的详细信息。

GOGC的默认值

GOGC参数可以使用runtime/debug包中的debug.SetGCPercent进行设置，GOGC默认设置为100%。

用下面命令运行程序:

go run main.go

程序执行后，将会创建trace.out文件，可以使用go tool工具对其进行分析。要做到这一点，执行命令:

go tool trace trace.out

然后可以通过打开web浏览器并访问http://127.0.0.1:54784/trace来查看基于web的跟踪查看器。

GOGC = 100
GOGC = 100

在"STATS"选项卡中，可以看到"Heap"字段，显示了在应用程序执行期间堆大小的变化情况，图中红色区域表示堆占用的内存。

在"PROCS"选项卡中，"GC"(垃圾收集器)字段显示的蓝色列表示触发垃圾收集器的时刻。

一旦新堆的大小达到活动堆大小的100%，就会触发垃圾收集。例如，如果活跃堆大小为10 MB，则当当前堆大小达到10 MB时将触发垃圾收集。

跟踪所有垃圾收集调用使我们能够确定垃圾收集器处于活动状态的总时间。

GOGC=100时的GC调用次数
GOGC=100时的GC调用次数

示例中，当GOGC值为100时，将调用垃圾收集器16次，总执行时间为14 ms。

更频繁的调用GC

如果我们将debug.SetGCPercent(10)设置为10%后运行代码，将观察到垃圾收集器调用的频率更高。现在，如果当前堆大小达到活跃堆大小的10%时，将触发垃圾收集。

换句话说，如果活跃堆大小为10 MB，则当前堆大小达到1 MB时就将触发垃圾收集。

GOGC = 10
GOGC = 10

在本例中，垃圾收集器被调用了38次，总垃圾收集时间为28 ms。

GOGC=10时的GC调用次数
GOGC=10时的GC调用次数

可以观察到，将GOGC设置为低于100%的值可以增加垃圾收集的频率，可能导致CPU使用率增加并降低程序性能。

更少的调用GC

如果运行相同程序，但将debug.SetGCPercent(1000)设置为1000%，我们将得到以下结果:

GOGC = 1000
GOGC = 1000

可以看到，当前堆的大小一直在增长，直到达到活跃堆大小的1000%。换句话说，如果活跃堆大小为10 MB，则当前堆大小达到100 MB时将触发垃圾收集。

GOGC=1000时的GC调用次数
GOGC=1000时的GC调用次数

在当前情况下，垃圾收集器被调用一次并执行2毫秒。

关闭GC

还可以通过设置GOGC=off或调用debug.SetGCPercent(-1)来禁用垃圾收集。

下面是禁用垃圾收集器而不设置GOMEMLIMIT时堆的行为:

当GC=off时，堆大小不断增长。
当GC=off时，堆大小不断增长。

可以看到，在关闭GC后，应用程序的堆大小一直在增长，直到程序执行为止。

堆占用多少内存?

在活跃堆的实际内存分配中，通常不像我们在trace中看到的那样定期和可预测的工作。

活跃堆随着每个垃圾收集周期动态变化，并且在某些条件下，其绝对值可能出现峰值。

例如，如果由于多个并行任务的重叠，活跃堆的大小可以增长到800 MB，那么只有在当前堆大小达到1.6 GB时才会触发垃圾收集。

alt

现代开发通常在具有内存使用限制的容器中运行应用。因此，如果容器将内存限制设置为1 GB，并且总堆大小增加到1.6 GB，则容器将失效，并出现OOM(out of memory)错误。

让我们模拟一下这种情况。例如，我们在内存限制为10 MB的容器中运行程序(仅用于测试目的)。Dockerfile:

FROM golang:latest as builder


WORKDIR /src
COPY . .


RUN go env -w GO111MODULE=on


RUN go mod vendor
RUN CGO_ENABLED=0 GOOS=linux go build -mod=vendor -a -installsuffix cgo -o app ./cmd/


FROM golang:latest
WORKDIR /root/
COPY --from=builder /src/app .
EXPOSE 8080
CMD ["./app"]

Docker-compose描述:

version: '3'
services:
 my-app:
   build:
     context: .
     dockerfile: Dockerfile
   ports:
     - 8080:8080
   deploy:
     resources:
       limits:
         memory: 10M

让我们使用前面设置GOGC=1000%的代码启动容器。

可以使用以下命令运行容器:

docker-compose build
docker-compose up

几秒钟后，容器将崩溃，并产生与OOM相对应的错误。

exited with code 137

这种情况非常令人不快: GOGC只控制新堆的相对值，而容器有绝对限制。

alt
如何避免OOM?

从1.19版本开始，在GOMEMLIMIT选项的帮助下，Golang引入了一个名为"软内存管理"的特性，runtime/debug包中名为SetMemoryLimit的类似函数(可以阅读48409-soft-memory-limit.md了解有关此选项的一些有趣的设计细节)提供了相同的功能。

GOMEMLIMIT环境变量设置Go运行时可以使用的总体内存限制，例如: GOMEMLIMIT = 8MiB。要设置内存值，需要使用大小后缀，在本例中为8 MB。

让我们启动将GOMEMLIMIT境变量设置为8MiB的容器。为此，我们将环境变量添加到docker-compose文件中:

version: '3'
services:
 my-app:
    environment:
      GOMEMLIMIT: "8MiB"
   build:
     context: .
     dockerfile: Dockerfile
   ports:
     - 8080:8080
   deploy:
     resources:
       limits:
         memory: 10M

现在，当启动容器时，程序运行没有任何错误。该机制是专门为解决OOM问题而设计的。

这是因为启用GOMEMLIMIT=8MiB后，会定期调用垃圾收集器，并将堆大小保持在一定限制内，结果就是会频繁调用垃圾收集器以避免内存过载。

运行垃圾收集器以使堆大小保持在一定的限制内。
运行垃圾收集器以使堆大小保持在一定的限制内。
成本是什么?

GOMEMLIMIT是强有力的工具，但也可能适得其反。

在上面的堆跟踪图中可以看到这种场景的一个示例。

当总内存大小由于活跃堆或持久程序泄漏的增长而接近GOMEMLIMIT时，将开始根据该限制不断调用垃圾收集器。

由于频繁调用垃圾收集器，应用程序的运行时可能会无限增加，从而消耗应用程序的CPU时间。

这种行为被称为死亡螺旋[5]，可能导致应用程序性能下降，与OOM错误不同，这种问题很难检测和修复。

这正是GOMEMLIMIT机制作为软限制起作用的原因。

Go不能100%保证GOMEMLIMIT指定的内存限制会被严格执行，而是会允许使用超出限制的内存，并防止频繁调用垃圾收集器的情况。

为了实现这一点，需要对CPU使用设置限制。目前，这个限制被设置为所有处理器时间的50%，CPU窗口为2 * GOMAXPROCS秒。

这就是为什么我们不能完全避免OOM错误，而是会将其推迟到很久以后发生。

在哪里应用GOMEMLIMIT和GOGC

如果默认垃圾收集器设置在大多数情况下是足够的，那么带有GOMEMLIMIT的软内存管理机制可以使我们避免不愉快的情况。

使用GOMEMLIMIT内存限制可能有用的例子:

  • 在内存有限的容器中运行应用程序时，最好将 GOMEMLIMIT设置为保留5-10%的可用内存。
  • 在运行资源密集型库或代码时，对 GOMEMLIMIT进行实时管理是有好处的。
  • 当在容器中以脚本形式运行应用程序时(意味着应用程序在一段时间内执行某些任务，然后终止)，禁用垃圾收集器但设置 GOMEMLIMIT可以提高性能并防止超出容器的资源限制。

避免使用GOMEMLIMIT的情况:

  • 当程序已经接近其环境的内存限制时，不要设置内存限制。
  • 在无法控制的执行环境中部署时，不要使用内存限制，特别是在程序的内存使用与其输入数据成正比的情况下，例如CLI工具或桌面应用程序。

如上所述，通过深思熟虑的方法，我们可以管理程序中的微调设置，例如垃圾收集器和GOMEMLIMIT。然而，仔细考虑应用这些设置的策略无疑非常重要。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！

参考资料
[1]

A Guide to the Go Garbage Collector: https://tip.golang.org/doc/gc-guide

 [2]

mgc.go: https://go.dev/src/runtime/mgc.go

 [3]

malloc.go: https://go.dev/src/runtime/malloc.go

 [4]

mgc.go: https://go.dev/src/runtime/mgc.go

 [5]

Soft Memory Limit Death Spirals: https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md#death-spirals

本文由 mdnice 多平台发布

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://xiahunao.cn/news/2776209.html

如若内容造成侵权/违法违规/事实不符，请联系瞎胡闹网进行投诉反馈，一经查实，立即删除！

相关文章

MySQL ——group by子句使用with rollup

MySQL ——group by子句使用with rollup

group by 子句使用with rollup关键字之后&#xff0c;具有分组加和的功能。即&#xff1a;在所有的分组记录之后&#xff0c;自动新增一条记录&#xff0c;从全局计算所有记录的数据。 0 问题描述 求出每年的学生平均成绩&#xff0c;及历史至今的平均成绩&#xff0c;结果保留…
阅读更多...
Linux线程 分离和同步与互斥 条件变量

Linux线程 分离和同步与互斥 条件变量

Linux线程 分离和同步与互斥 条件变量 1. 分离线程2. 线程互斥与互斥量3. 线程同步与竞态条件4. pthread库与条件变量5. 生产者-消费者 1. 分离线程 什么是线程分离&#xff1f; 线程分离是指线程在结束时&#xff0c;操作系统会自动回收其资源&#xff0c;而无需其他线程显式地…
阅读更多...
【开源】JAVA+Vue+SpringBoot实现公司货物订单管理系统

【开源】JAVA+Vue+SpringBoot实现公司货物订单管理系统

目录 一、摘要1.1 项目介绍1.2 项目录屏 二、功能模块2.1 客户管理模块2.2 商品维护模块2.3 供应商管理模块2.4 订单管理模块 三、系统展示四、核心代码4.1 查询供应商信息4.2 新增商品信息4.3 查询客户信息4.4 新增订单信息4.5 添加跟进子订单 五、免责说明 一、摘要 1.1 项目…
阅读更多...
[自然语言处理|NLP] 文本分类与情感分析，数据预处理流程，包括了同义词替换和拼写纠正，以及使用NLTK库和TextBlob库进行标记化和情感分析（附代码）

[自然语言处理|NLP] 文本分类与情感分析，数据预处理流程，包括了同义词替换和拼写纠正，以及使用NLTK库和TextBlob库进行标记化和情感分析（附代码）

[自然语言处理|NLP] 文本分类与情感分析，数据预处理流程，包括了同义词替换和拼写纠正，以及使用NLTK库和TextBlob库进行标记化和情感分析（附代码）。 自然语言处理（Natural Language Processing，简称NLP）是人工智能领域的一个重要分支，涉及了处理和理解人类语言的技术…
阅读更多...
百卓Smart管理平台 uploadfile.php 文件上传漏洞(CVE-2024-0939)

百卓Smart管理平台 uploadfile.php 文件上传漏洞(CVE-2024-0939)

免责声明&#xff1a;文章来源互联网收集整理&#xff0c;请勿利用文章内的相关技术从事非法测试&#xff0c;由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失&#xff0c;均由使用者本人负责&#xff0c;所产生的一切不良后果与文章作者无关。该…
阅读更多...
除夕日的每日一题（字符个数统计，多数元素）

除夕日的每日一题（字符个数统计，多数元素）

字符个数统计_牛客题霸_牛客网 (nowcoder.com) #include <stdio.h> #include <string.h> #include <stdlib.h>int num0,len,i,j,k,asc; int tmp[128]{0}; char str[400]; int main() {gets(str);//gets(str) 用于从标准输入读取一个字符串并存储在 str 中len…
阅读更多...
「递归算法」：合并两个有序链表

「递归算法」：合并两个有序链表

一、题目 将两个升序链表合并为一个新的 升序 链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。 示例 1&#xff1a; 输入&#xff1a;l1 [1,2,4], l2 [1,3,4] 输出&#xff1a;[1,1,2,3,4,4]示例 2&#xff1a; 输入&#xff1a;l1 [], l2 [] 输出&#…
阅读更多...
华为第二批难题一：基于预训练AI模型的元件库生成

华为第二批难题一：基于预训练AI模型的元件库生成

我的理解&#xff1a;华为的这个难道应该是想通过大模型技术&#xff0c;识别元件手册上的图文内容&#xff0c;与现有建库工具结合&#xff0c;有潜力按标准生成各种库模型。 正好&#xff0c;我们正在研究&#xff0c;利用知识图谱技术快速生成装配模型&#xff0c;其中也涉…
阅读更多...
有关网络安全的课程学习网页

有关网络安全的课程学习网页

1.思科网络学院 免费学习skillsforall的课程 课程链接&#xff1a;Introduction to Cybersecurity by Cisco: Free Online Course (skillsforall.com) 2.斯坦福大学计算机和网络安全基础 该证书对于初学者来说最有价值&#xff0c;它由最著名的大学之一斯坦福大学提供。您可…
阅读更多...
基于YOLOv7算法的高精度实时老鼠目标检测系统（PyTorch+Pyside6+YOLOv7）

基于YOLOv7算法的高精度实时老鼠目标检测系统（PyTorch+Pyside6+YOLOv7）

摘要&#xff1a;基于YOLOv7算的高精度实时老鼠目标检测系统可用于日常生活中检测与定位老鼠目标&#xff0c;此系统可完成对输入图片、视频、文件夹以及摄像头方式的目标检测与识别&#xff0c;同时本系统还支持检测结果可视化与导出。本系统采用YOLOv7目标检测算法来训练数据…
阅读更多...
nodejs+vue高校实验室耗材管理系统_m20vy

nodejs+vue高校实验室耗材管理系统_m20vy

用户功能&#xff1a; 登录后要有一个首页 比如:可以看见目前的耗材消耗记录&#xff0c;可做成图表菜单栏在左侧显示 1.个人信息管理 可以对基本信息进行修改&#xff0c;(修改密码时需要验证) 2.耗材管理&#xff08;耗材信息&#xff09; 普通用户可以查询当前相关耗材信息[…
阅读更多...
【数据结构与算法】力扣刷题记之 稀疏数组

【数据结构与算法】力扣刷题记之 稀疏数组

&#x1f389;&#x1f389;欢迎光临&#x1f389;&#x1f389; &#x1f3c5;我是苏泽&#xff0c;一位对技术充满热情的探索者和分享者。&#x1f680;&#x1f680; &#x1f31f;特别推荐给大家我的最新专栏《数据结构与算法&#xff1a;初学者入门指南》&#x1f4d8;&am…
阅读更多...
OCP使用CLI创建和构建应用

OCP使用CLI创建和构建应用

文章目录 环境登录创建project赋予查看权限部署第一个image创建route检查pod扩展应用 部署一个Python应用连接数据库创建secret加载数据并显示国家公园地图 清理参考 环境 RHEL 9.3Red Hat OpenShift Local 2.32 登录 通过 crc console --credentials 可以查看登录信息&…
阅读更多...
CS50x 2024 - Lecture 2 - Arrays

CS50x 2024 - Lecture 2 - Arrays

00:00:00 - Introduction 00:01:01 - Story Time 00:06:03 - Compiling make本身并不是编译器&#xff0c;实际上是一个自动运行编译器的程序&#xff0c;如c语言的clang clang -o hello hello.csrc/ $ clang -o hello hello_world.c /usr/bin/ld: /tmp/hello_world-67f51…
阅读更多...
【VTKExamples::PolyData】第二十四期 InterpolateTerrain

【VTKExamples::PolyData】第二十四期 InterpolateTerrain

很高兴在雪易的CSDN遇见你 VTK技术爱好者 QQ：870202403 前言 本文分享VTK样例InterpolateTerrain，希望对各位小伙伴有所帮助！ 感谢各位小伙伴的点赞+关注，小易会继续努力分享，一起进步！ 你的点赞就是我的动力(＾Ｕ＾)ノ~ＹＯ 1. InterpolateTerrain 输出： Interp…
阅读更多...
FX110网：如何判断行情是真突破还是假突破？

FX110网：如何判断行情是真突破还是假突破？

众所周知&#xff0c;在交易过程中&#xff0c;趋向线的突破对买入、卖出时机等选择具有重要的分析意义。因此&#xff0c;搞清趋势线何时突破&#xff0c;是有效的突破还是非有效的突破&#xff0c;于投资者而言是至关重要的。 本文将提供一些对于趋向线突破的判断方法和市场原…
阅读更多...
软考 系统分析师系列知识点之信息系统战略规划方法（4）

软考 系统分析师系列知识点之信息系统战略规划方法（4）

接前一篇文章&#xff1a;软考 系统分析师系列知识点之信息系统战略规划方法&#xff08;3&#xff09; 所属章节&#xff1a; 第7章. 企业信息化战略与实施 第4节. 信息系统战略规划方法 7.4.2 关键成功因素法 关键成功因素&#xff08;Critical Success Factors&#xff0c…
阅读更多...
PySpark（四）PySpark SQL、Catalyst优化器、Spark SQL的执行流程、Spark新特性

PySpark（四）PySpark SQL、Catalyst优化器、Spark SQL的执行流程、Spark新特性

目录 PySpark SQL 基础 SparkSession对象 DataFrame入门 DataFrame构建 DataFrame代码风格 DSL SQL SparkSQL Shuffle 分区数目 DataFrame数据写出 Spark UDF Catalyst优化器 Spark SQL的执行流程 Spark新特性 自适应查询(SparkSQL) 动态合并 动态调整Join策略 …
阅读更多...
Redis篇之持久化

Redis篇之持久化

一、为什么要进行持久化 Redis是一个基于内存的键值存储系统&#xff0c;但为了保证数据在服务器重启、故障等情况下不丢失。 二、应该怎么持久化 1.RDB持久化 &#xff08;1&#xff09;RDB是什么 RDB全称Redis Database Backup file&#xff08;Redis数据备份文件&#xff…
阅读更多...
Android性能调优 - 应用安全问题

Android性能调优 - 应用安全问题

Android应用安全 1.组件暴露&#xff1a; 像比如ContentProvider,BroadcastReceiver&#xff0c;Activity等组件有android:exported属性&#xff1b; 如果是私有组件 android:exported “false”&#xff1b; 如果是公有组件 android:exported “true” 且进行权限控制&…
阅读更多...
最新文章

Copyright @ 2022~2023