面包芯语

go的net/http有哪些值得关注的细节？

原创 小白debug 2023-08-14 08:33
采样电阻OUT！Allegro磁传感方案实战揭秘 实测解析：高精度电流传感在BMS与智能家居中的设计取舍

golang的net/http库是我们平时写代码中，非常常用的标准库。由于go语言拥有goroutine，goroutine的上下文切换成本比普通线程低很多，net/http库充分利用了这个优势，因此，它的内部实现跟其他语言会有一些区别。

其中最大的区别在于，其他语言中，一般是多个网络句柄共用一个或多个线程，以此来减少线程之间的切换成本。而golang则会为每个网络句柄创建两个goroutine，一个用于读数据，一个用于写数据。

读写协程

下图是net/http源码中创建这两个goroutine的地方。

源码中创建两个协程的地方

了解它的内部实现原理，可以帮助我们写出更高性能的代码，以及避免协程泄露造成的内存泄漏问题。

这篇文章是希望通过几个例子让大家对net/http的内部实现有更直观的理解。


连接与协程数量的关系

首先我们来看一个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码做的事情很简单，执行5次循环http请求，最终通过runtime.NumGoroutine()方法打印当前的goroutine数量。

代码里只有三个地方需要注意：

  1. 1. Transport设置了一个3s的空闲连接超时

  2. 2. for循环执行了5次http请求

  3. 3. 程序退出前执行了5s sleep

答案输出1。也就是说当程序退出的时候，当前的goroutine数量为1，毫无疑问它指的是正在运行main方法的goroutine，后面我们都叫它main goroutine。

再来看个例子。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

在原来的基础上，我们程序退出前的睡眠时间，从5s改成1s，此时输出3。也就是说除了main方法所在的goroutine，还多了两个goroutine，我们大概也能猜到，这就是文章开头提到的读goroutine和写goroutine。也就是说程序在退出时，还有一个网络连接没有断开。

这是一个TCP长连接。

HTTP1.1底层依赖TCP

网络五层模型中，HTTP处于应用层，它的底层依赖了传输层的TCP协议。

当我们发起http请求时，如果每次都要建立新的TCP协议，那就需要每次都经历三次握手，这会影响性能，因此更好的方式就是在http请求结束后，不立马断开TCP连接，将它放到一个空闲连接池中，后续有新的http请求时就复用该连接。

像这种长时间存活，被多个http请求复用的TCP连接，就是所谓的长连接。反过来，如果每次HTTP请求结束就将TCP连接进行四次挥手断开，下次有需要执行HTTP调用时就再建立，这样的TCP连接就是所谓的短连接。

HTTP1.1之后默认使用长连接。

连接池复用连接

那为什么这跟5s和1s有关系？

这是因为长连接在空闲连接池也不能一直存放着，如果一直没被使用放着也是浪费资源，因此会有个空闲回收时间，也就是上面代码中的IdleConnTimeout，我们设置的是3s，当代码在结束前sleep了5s后，长连接就已经被释放了，因此输出结果是只剩一个main goroutine。当sleep 1s时，长连接还在空闲连接池里，因此程序结束时，就还剩3个goroutine（main goroutine+网络读goroutine+网络写goroutine）。

我们可以改下代码下验证这个说法。我们知道，HTTP可以通过connection的header头来控制这次的HTTP请求是用的长连接还是短连接。connection:keep-alive 表示http请求结束后，tcp连接保持存活，也就是长连接， connection:close则是短连接。

req.Header.Add("connection", "close")

就像下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        req.Header.Add("connection", "close")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时，会发现，程序重新输出1。完全符合我们预期。


resp.body是否读取对连接复用的影响

func main() {
   n := 5
   for i := 0; i < n; i++ {
      resp, _ := http.Get("https://www.baidu.com")
      _ = resp.Body.Close()
   }
   fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里没有执行 ioutil.ReadAll(resp.Body)。也就是说http请求响应的结果并没有被读取的情况下，net/http库会怎么处理。

上面的代码最终输出3，分别是main goroutine，read goroutine 以及write goroutine。也就是说长连接没有断开，那长连接是会在下一次http请求中被复用吗？先说答案，不会复用。

我们可以看代码。resp.Body.Close() 会执行到 func (es * bodyEOFSignal) Close() error 中，并执行到es.earlyCloseFn()中。

earlyCloseFn的逻辑也非常简单，就是将一个false传入到waitForBodyRead的channel中。那写入通道后的数据会在另外一个地方被读取，我们来看下读取的地方。

bodyEOF为false, 也就不需要执行 tryPutIdleConn()方法。

tryPutIdleConn会将连接放到长连接池中备用）。

最终就是alive=bodyEOF ，也就是false，字面意思就是该连接不再存活。因此该长连接并不会复用，而是会释放。

那为什么output输出为3？这是因为长连接释放需要时间。

我们可以在结束前加一个休眠，比如再执行休眠1毫秒。

func main() {
    n := 5
    for i := 0; i < n; i++ {
        resp, _ := http.Get("https://www.baidu.com")
        _ = resp.Body.Close()
    }
    time.Sleep(time.Millisecond * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时就会输出1。说明协程是退出中的，只是没来得及完全退出，休眠1ms后彻底退出了。

如果我们，将在代码中重新加入 ioutil.ReadAll(resp.Body)，就像下面这样。

func main() {
    n := 5
    for i := 0; i < n; i++ {
        resp, _ := http.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

此时，output还是输出3，但这个3跟上面的3不太一样，休眠5s后还是输出3。这是因为长连接被推入到连接池了，连接会重新复用。

下面是源码的解释。


body.close()不执行会怎么样

网上都说不执行body.close()会协程泄漏（导致内存泄露），真的会出现协程泄漏吗，如果泄漏，会泄漏多少？

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        //_ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

我们可以运行这段代码，代码中将resp.body.close()注释掉，结果输出3。debug源码，会发现连接其实复用了。代码执行到tryPutIdleConn函数中，会将连接归还到空闲连接池中。

休眠5s，结果输出1，这说明达到idleConnTimeout，空闲连接断开。看起来一切正常。

将resp.Body.Close()那一行代码重新加回来，也就是下面这样，会发现代码结果依然输出3。我们是否删除这行代码，对结果没有任何影响。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

既然执不执行body.close()都没啥区别，那body.close()的作用是什么呢？

它是为了标记当前连接请求中，response.body是否使用完毕，如果不执行body.close()，则resp.Body中的数据是可以不断重复读且不报错的（但不一定能读到数据），执行了body.close()，再次去读取resp.Body则会报错，如果resp.body数据读一半，处理代码逻辑就报错了，此时你不希望其他地方继续去读，那就需要使用body.close()去关闭它。这更像是一种规范约束，它可以更好的保证数据正确。

也就是说不执行body.close()，并不一定会内存泄露。那么什么情况下会协程泄露呢？

直接说答案，既不执行 ioutil.ReadAll(resp.Body) 也不执行resp.Body.Close()，并且不设置http.Client内timeout的时候，就会导致协程泄露。

比如下面这样。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
        }
        resp, _ := client.Do(req)
        _ = resp
    }
    time.Sleep(time.Second * 5)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

最终结果会输出11，也就是1个main goroutine + （1个read goroutine + 1个read goroutine）* 5次http请求。

前面提到，不执行ioutil.ReadAll(resp.Body)，网络连接无法归还到连接池。不执行resp.Body.Close()，网络连接就无法为标记为关闭，也就无法正常断开。因此能导致协程泄露，非常好理解。

但http.Client内timeout有什么关系？这是因为timeout是指，从发起请求到从resp.body中读完响应数据的总时间，如果超过了，网络库会自动断开网络连接，并释放read+write goroutine。因此如果设置了timeout，则不会出现协程泄露的问题。

另外值得一提的是，我看到有不少代码都是直接用下面的方式去做网络请求的。

resp, _ := http.Get("https://www.baidu.com")

这种方式用的是DefaultClient，是没有设置超时的，生产环境中使用不当，很容易出现问题。

func Get(url string) (resp *Response, err error) {
    return DefaultClient.Get(url)
}

var DefaultClient = &Client{}


连接池的结构

我们了解到连接池可以复用网络连接，接下来我们通过一个例子来看看网络连接池的结构。


func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "http://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

注意这里请求的不是https，而是http。最终结果输出5，为什么？

这是因为，http://www.baidu.com会返回307，重定向到https://www.baidu.com。

http重定向为https

在网络中，我们可以通过一个五元组来唯一确定一个TCP连接。

五元组

它们分别是源ip，源端口，协议，目的ip，目的端口。只有当多次请求的五元组一样的情况下，才有可能复用连接。

放在我们这个场景下，源ip、源端口、协议都是确定的，也就是两次http请求的目的ip或目的端口有区别的时候，就需要使用不同的TCP长连接。

而http用的是80端口，https用的是443端口。于是连接池就为不同的网络目的地建立不同的长连接。

因此最终结果5个goroutine，其实2个goroutine来自http,2个goroutine来自https，1个main goroutine。

我们来看下源码的具体实现。net/http底层通过一个叫idleConn的map去存空闲连接，也就是空闲连接池。

idleConn这个map的key是协议和地址，其实本质上就是ip和端口。map的value是长连接的数组（[]*persistConn），说明net/http支持为同一个地址建立多个TCP连接，这样可以提升传输的吞吐。

连接池的结构和逻辑


Transport是什么？

Transport本质上是一个用来控制http调用行为的一个组件，里面包含超时控制，连接池等，其中最重要的是连接池相关的配置。

我们通过下面的例子感受下。

func main() {
    n := 5
    for i := 0; i < n; i++ {
        httpClient := &http.Client{}
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}
func main() {
    n := 5
    for i := 0; i < n; i++ {
        httpClient := &http.Client{
            Transport:  &http.Transport{},
        }
        resp, _ := httpClient.Get("https://www.baidu.com")
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

上面的代码第一个例子的代码会输出3。分别是main goroutine + read goroutine + write goroutine，也就是有一个被不断复用的TCP连接。

在第二例子中，当我们在每次client中都创建一个新的http.Transport，此时就会输出11。

说明TCP连接没有复用，每次请求都会产生新的连接。这是因为每个http.Transport内都会维护一个自己的空闲连接池，如果每个client都创建一个新的http.Transport，就会导致底层的TCP连接无法复用。如果网络请求过大，上面这种情况会导致协程数量变得非常多，导致服务不稳定。

因此，最佳实践是所有client都共用一个transport。

func main() {
    tr := &http.Transport{
        MaxIdleConns:    100,
        IdleConnTimeout: 3 * time.Second,
    }

    n := 5
    for i := 0; i < n; i++ {
        req, _ := http.NewRequest("POST", "https://www.baidu.com", nil)
        req.Header.Add("content-type", "application/json")
        client := &http.Client{
            Transport: tr,
            Timeout:   3 * time.Second,
        }
        resp, _ := client.Do(req)
        _, _ = ioutil.ReadAll(resp.Body)
        _ = resp.Body.Close()
    }
    time.Sleep(time.Second * 1)
    fmt.Printf("goroutine num is %d\n", runtime.NumGoroutine())
}

如果创建客户端的时候不指定http.Client，会默认所有http.Client都共用同一个DefaultTransport。这一点可以从源码里看出。

默认使用DefaultTransport
DefaultTransport

因此当第二段代码中，每次都重新创建一个Transport的时候，每个Transport内都会各自维护一个空闲连接池。因此每次建立长连接后都会多两个协程（读+写），对应1个main goroutine+（read goroutine + write goroutine）* 5 =11。


别设置 Transport.Dail里的SetDeadline

http.Transport.Dial的配置里有个SetDeadline，它表示连接建立后发送接收数据的超时时间。听起来跟client.Timeout很像。

那么他们有什么区别呢？我们通过一个例子去看下。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net"
    "net/http"
    "time"
)

var tr *http.Transport

func init() {
    tr = &http.Transport{
        MaxIdleConns: 100,
        Dial: func(netw, addr string) (net.Conn, error) {
            conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
            if err != nil {
                return nil, err
            }
            err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
            if err != nil {
                return nil, err
            }
            return conn, nil
        },
    }
}

func main() {
    for {
        _, err := Get("http://www.baidu.com/")
        if err != nil {
            fmt.Println(err)
            break
        }
    }
}


func Get(url string) ([]byte, error) {
    m := make(map[string]interface{})
    data, err := json.Marshal(m)
    if err != nil {
        return nil, err
    }
    body := bytes.NewReader(data)
    req, _ := http.NewRequest("Get", url, body)
    req.Header.Add("content-type", "application/json")

    client := &http.Client{
        Transport: tr,
    }
    res, err := client.Do(req)
    if res != nil {
        defer res.Body.Close()
    }
    if err != nil {
        return nil, err
    }
    resBody, err := ioutil.ReadAll(res.Body)
    if err != nil {
        return nil, err
    }
    return resBody, nil
}

上面这段代码，我们设置了SetDeadline为3s，当你执行一段时间，会发现请求baidu会超时，但其实baidu的接口很快，不可能超过3s。

在生产环境中，假如是你的服务调用下游服务，你看到的现象就是，你的服务显示3s超时了，但下游服务可能只花了200ms就已经响应你的请求了，并且这是随机发生的问题。遇到这种情况，我们一般会认为是“网络波动”。

但如果我们去对网络抓包，就很容易发现问题的原因 。

抓包结果

可以看到，在tcp三次握手之后，就会开始多次网络请求。直到3s的时候，就会触发RST包，断开连接。也就是说，我们设置的SetDeadline，并不是指单次http请求的超时是3s，而是指整个tcp连接的存活时间是3s，计算长连接被连接池回收，这个时间也不会重置。

SetDeadline的解释

我实在想不到什么样的场景会需要这个功能，因此我的建议是，不要使用它。

下面是修改后的代码。这个问题其实在我另外一篇文章有过详细的解释，如果你对源码解析感兴趣的话，可以去看看。

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io/ioutil"
    "net/http"
    "time"
)

var tr *http.Transport

func init() {
    tr = &http.Transport{
        MaxIdleConns: 100,
        // 下面的代码被干掉了
        //Dial: func(netw, addr string) (net.Conn, error) {
        // conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
        // if err != nil {
        //  return nil, err
        // }
        // err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
        // if err != nil {
        //  return nil, err
        // }
        // return conn, nil
        //},
    }
}


func Get(url string) ([]byte, error) {
    m := make(map[string]interface{})
    data, err := json.Marshal(m)
    if err != nil {
        return nil, err
    }
    body := bytes.NewReader(data)
    req, _ := http.NewRequest("Get", url, body)
    req.Header.Add("content-type", "application/json")

    client := &http.Client{
        Transport: tr,
        Timeout: 3*time.Second,  // 超时加在这里，是每次调用的超时
    }
    res, err := client.Do(req) 
    if res != nil {
        defer res.Body.Close()
    }
    if err != nil {
        return nil, err
    }
    resBody, err := ioutil.ReadAll(res.Body)
    if err != nil {
        return nil, err
    }
    return resBody, nil
}

func main() {
    for {
        _, err := Get("http://www.baidu.com/")
        if err != nil {
            fmt.Println(err)
            break
        }
    }
}

总结

golang的net/http部分有不少细节点，直接上源码分析怕劝退不少人，所以希望以几个例子作为引子展开话题然后深入了解它的内部实现。总体内容比较碎片化，但这个库的重点知识点基本都在这里面了。希望对大家后续排查问题有帮助。

最后

离开广东好长时间了，好久没人叫我靓仔了。

大家可以在评论区里，叫我一靓仔吗？

我这么善良质朴的愿望，能被满足吗？

如果实在叫不出口的话，能帮我点下右下角的点赞和在看吗？


别说了，一起在知识的海洋里呛水吧

点击下方名片，关注公众号:【小白debug】

不满足于在留言区说骚话？

加我，我们建了个划水吹牛皮群，在群里，你可以跟你下次跳槽可能遇到的同事或面试官聊点有意思的话题。就超！开！心！

文章推荐：

  • • 程序员防猝死指南

  • • TCP粘包 数据包：我只是犯了每个数据包都会犯的错 |硬核图解

  • • 动图图解！既然IP层会分片，为什么TCP层也还要分段？


登录阅读全文
免责声明： 该内容由专栏作者授权发布或作者转载，目的在于传递更多信息，并不代表本网赞同其观点，本站亦不保证或承诺内容真实性等。若内容或图片侵犯您的权益，请及时联系本站删除。侵权投诉联系：  nick.zong@aspencore.com！
小白debug
评论
  • Vscode C语言编程环境配置
    1,微软下载免费Visual Studio Code2,安装C/C++插件,如果无法直接点击下载, 可以选择手动install from VSIX:ms-vscode.cpptools-1.23.6@win32-x64.vsix3,安装C/C++编译器MniGW (MinGW在 Windows 环境下提供类似于 Unix/Linux 环境下的开发工具，使开发者能够轻松地在 Windows 上编写和编译 C、C++ 等程序.)4,C/C++插件扩展设置中添加Include Path 5,
    黎查 2025-02-28 14:39 101浏览
  • 广电计量出版FIB领域专著，赋能半导体质量精准提升
            近日，广电计量在聚焦离子束（FIB）领域编写的专业著作《聚焦离子束：失效分析》正式出版，填补了国内聚焦离子束领域实践性专业书籍的空白，为该领域的技术发展与知识传播提供了重要助力。         随着芯片技术不断发展，芯片的集成度越来越高，结构也日益复杂。这使得传统的失效分析方法面临巨大挑战。FIB技术的出现，为芯片失效分析带来了新的解决方案。它能够在纳米尺度上对芯片进行精确加工和分析。当芯
    广电计量 2025-02-28 09:15 89浏览
  • 震动样品磁强计VSM测量什么
    一、VSM的基本原理震动样品磁强计（Vibrating Sample Magnetometer，简称VSM）是一种灵敏且高效的磁性测量仪器。其基本工作原理是利用震动样品在探测线圈中引起的变化磁场来产生感应电压，这个感应电压与样品的磁矩成正比。因此，通过测量这个感应电压，我们就能够精确地确定样品的磁矩。在VSM中，被测量的样品通常被固定在一个震动头上，并以一定的频率和振幅震动。这种震动在探测线圈中引起了变化的磁通量，从而产生了一个交流电信号。这个信号的幅度和样品的磁矩有着直接的关系。因此，通过仔细
    锦正茂科技 2025-02-28 13:30 80浏览
  • 高性能、远距离SoC无线收发模块RFM25A12
    在物联网领域中，无线射频技术作为设备间通信的核心手段，已深度渗透工业自动化、智慧城市及智能家居等多元场景。然而，随着物联网设备接入规模的不断扩大，如何降低运维成本，提升通信数据的传输速度和响应时间，实现更广泛、更稳定的覆盖已成为当前亟待解决的系统性难题。SoC无线收发模块-RFM25A12在此背景下，华普微创新推出了一款高性能、远距离与高性价比的Sub-GHz无线SoC收发模块RFM25A12，旨在提升射频性能以满足行业中日益增长与复杂的设备互联需求。值得一提的是，RFM25A12还支持Wi-S
    华普微HOPERF 2025-02-28 09:06 104浏览
  • 振动样品磁强计测量准确度的影响因素
    振动样品磁强计是一种用于测量材料磁性的精密仪器，广泛应用于科研、工业检测等领域。然而，其测量准确度会受到多种因素的影响，下面我们将逐一分析这些因素。一、温度因素温度是影响振动样品磁强计测量准确度的重要因素之一。随着温度的变化，材料的磁性也会发生变化，从而影响测量结果的准确性。因此，在进行磁性测量时，应确保恒温环境，以减少温度波动对测量结果的影响。二、样品制备样品的制备过程同样会影响振动样品磁强计的测量准确度。样品的形状、尺寸和表面处理等因素都会对测量结果产生影响。为了确保测量准确度，应严格按照规
    锦正茂科技 2025-02-28 14:05 118浏览
  • 参加《广东省科技创新条例》宣讲会
              近日受某专业机构邀请，参加了官方举办的《广东省科技创新条例》宣讲会。在与会之前，作为一名技术工作者一直认为技术的法例都是保密和侵权方面的，而潜意识中感觉法律有束缚创新工作的进行可能。通过一个上午学习新法，对广东省的科技创新有了新的认识。广东是改革的前沿阵地，是科技创新的沃土，企业是创新的主要个体。《广东省科技创新条例》是广东省为促进科技创新、推动高质量发展而制定的地方性法规，主要内容包括： 总则：明确立法目
    广州铁金刚 2025-02-28 10:14 90浏览
  • 美国加州CEC能效跟DOE能效有什么区别？CEC/DOE是什么关系?
    美国加州CEC能效跟DOE能效有什么区别？CEC/DOE是什么关系?美国加州CEC能效跟DOE能效有什么区别？CEC/DOE是什么关系?‌美国加州CEC能效认证与美国DOE能效认证在多个方面存在显著差异‌。认证范围和适用地区‌CEC能效认证‌：仅适用于在加利福尼亚州销售的电器产品。CEC认证的范围包括制冷设备、房间空调、中央空调、便携式空调、加热器、热水器、游泳池加热器、卫浴配件、光源、应急灯具、交通信号模块、灯具、洗碗机、洗衣机、干衣机、烹饪器具、电机和压缩机、变压器、外置电源、消费类电子设备
    张工nx808593 2025-02-27 18:04 99浏览
  • 为什么说Matter是智能家居厂商的“通关密码”？
    Matter 协议，原名 CHIP（Connected Home over IP），是由苹果、谷歌、亚马逊和三星等科技巨头联合ZigBee联盟（现连接标准联盟CSA）共同推出的一套基于IP协议的智能家居连接标准，旨在打破智能家居设备之间的 “语言障碍”，实现真正的互联互通。然而，目标与现实之间总有落差，前期阶段的Matter 协议由于设备支持类型有限、设备生态协同滞后以及设备通信协议割裂等原因，并未能彻底消除智能家居中的“设备孤岛”现象，但随着2025年的到来，这些现象都将得到完美的解决。近期，
    华普微HOPERF 2025-02-27 10:32 180浏览
  • RGB灯光无法同步？细致的动态光效设定反而成为产品客诉来源！
    RGB灯光无法同步？细致的动态光效设定反而成为产品客诉来源！随着科技的进步和消费者需求变化，电脑接口设备单一功能性已无法满足市场需求，因此在产品上增加「动态光效」的形式便应运而生，藉此吸引消费者目光。这种RGB灯光效果，不仅能增强电脑周边产品的视觉吸引力，还能为用户提供个性化的体验，展现独特自我风格。如今，笔记本电脑、键盘、鼠标、鼠标垫、耳机、显示器等多种电脑接口设备多数已配备动态光效。这些设备的灯光效果会随着音乐节奏、游戏情节或使用者的设置而变化。想象一个画面，当一名游戏玩家，按下电源开关，整
    百佳泰测试实验室 2025-02-27 14:15 133浏览
  • 可穿戴健康监测新趋势，艾迈斯欧司朗的创新 “智” 造
    更多生命体征指标风靡的背后都只有一个原因：更多人将健康排在人生第一顺位！“AGEs，也就是晚期糖基化终末产物，英文名Advanced Glycation End-products，是存在于我们体内的一种代谢产物” 艾迈斯欧司朗亚太区健康监测高级市场经理王亚琴说道，“相信业内的朋友都会有关注，最近该指标的热度很高，它可以用来评估人的生活方式是否健康。”据悉，AGEs是可穿戴健康监测领域的一个“萌新”指标，近来备受关注。如果站在学术角度来理解它，那么AGEs是在非酶促条件下，蛋白质、氨基酸
    艾迈斯欧司朗 2025-02-27 14:50 367浏览
  • 天下共赴具身智能，车企纷纷入局，未来已来？
    在2024年的科技征程中，具身智能的发展已成为全球关注的焦点。从实验室到现实应用，这一领域正以前所未有的速度推进，改写着人类与机器的互动边界。这一年，我们见证了具身智能技术的突破与变革，它不仅落地各行各业，带来新的机遇，更在深刻影响着我们的生活方式和思维方式。随着相关技术的飞速发展，具身智能不再仅仅是一个技术概念，更像是一把神奇的钥匙。身后的众多行业，无论愿意与否，都像是被卷入一场伟大变革浪潮中的船只，注定要被这股汹涌的力量重塑航向。01为什么是具身智能？为什么在中国？最近，中国具身智能行业的进
    艾迈斯欧司朗 2025-02-28 15:45 165浏览
  • AI PC潜力无限却挑战重重，测试验证如何破局？
    应用趋势与客户需求，AI PC的未来展望随着人工智能(AI)技术的日益成熟，AI PC(人工智能个人电脑)逐渐成为消费者和企业工作中的重要工具。这类产品集成了最新的AI处理器，如NPU、CPU和GPU，并具备许多智能化功能，为用户带来更高效且直观的操作体验。AI PC的目标是提升工作和日常生活的效率，通过深度学习与自然语言处理等技术，实现更流畅的多任务处理、实时翻译、语音助手、图像生成等功能，满足现代用户对生产力和娱乐的双重需求。随着各行各业对数字转型需求的增长，AI PC也开始在各个领域中显示
    百佳泰测试实验室 2025-02-27 14:08 238浏览
我要评论
0
点击右上角，分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦