Netty Review - 从BIO到NIO的进化推演

news2024/11/20 20:22:06

文章目录

  • BIO
    • DEMO 1
    • DEMO 2
    • 小结论
    • 单线程BIO的缺陷
    • BIO如何处理并发
    • 多线程BIO服务器的弊端
  • NIO
    • NIO要解决的问题
    • 模拟NIO
      • 方案一： （等待连接时和等待数据时不阻塞）
      • 方案二（缓存Socket，轮询数据是否准备好）
      • 方案二存在的问题
    • NIO是如何解决这些问题的
    • 使用select/poll/epoll和直接在应用层做轮询的区别
      • select底层逻辑
      • poll的底层逻辑
      • epoll的底层逻辑

在这里插入图片描述

BIO

要讲明白BIO和NIO，首先我们应该自己实现一个简易的服务器，单线程即可。

DEMO 1

package com.artisan.bio;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class Server {
    public static void main(String[] args) {

        // BIO 面向字节
        byte[] bytes = new byte[1024];

        ServerSocket serverSocket = null;
        try {
            serverSocket = new ServerSocket(1234);
            System.out.println("服务端已开启端口");

            while (true) {
                System.out.println();

                System.out.println("服务端等待连接......");

                Socket socket = serverSocket.accept();
                System.out.println("服务端已经收到连接请求");

                System.out.println("服务端等待数据.....");

                socket.getInputStream().read(bytes);
                System.out.println("服务端等已收到数据.....");

                String msg = new String(bytes);

                System.out.println("接收到了数据: " + msg);
            }

        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

创建了一个服务端类，在类中实现实例化了一个SocketServer并绑定了1234端口。之后调用accept方法来接收连接请求，并且调用read方法来接收客户端发送的数据。最后将接收到的数据打印。

package com.artisan.bio;

import java.io.IOException;
import java.net.Socket; 

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class Client {

    public static void main(String[] args) throws IOException {

        Socket socket = new Socket("127.0.0.1",1234);

        socket.getOutputStream().write("数据数据数据".getBytes());

        socket.close();

    }
}

客户端，首先实例化Socket对象，并且绑定ip为127.0.0.1（本机），端口号为1234，调用write方法向服务器发送数据

运行测试会发现

在服务器启动后，客户端还没有连接服务器时，服务器由于调用了accept方法，将一直阻塞，直到有客户端请求连接服务器。

DEMO 2

客户端的逻辑主要是：建立Socket –> 连接服务器 –> 发送数据，我们的数据是在连接服务器之后就立即发送的，现在我们来对客户端进行一次扩展，当我们连接服务器后，不立即发送数据，而是等待控制台手动输入数据后，再发送给服务端

客户端代码如下

 try {
         Socket socket = new Socket("127.0.0.1",1234);
           String message = null;
           Scanner sc = new Scanner(System.in);
           message = sc.next();
           socket.getOutputStream().write(message.getBytes());
           socket.close();
           sc.close();
   } catch (IOException e) {
           // TODO Auto-generated catch block
           e.printStackTrace();
   }

小结论

在这里插入图片描述

从上面的运行结果中我们可以看到，服务器端在启动后：

1）首先需要等待客户端的连接请求（第一次阻塞）；

2）如果没有客户端连接，服务端将一直阻塞等待；

3）然后当客户端连接后，服务器会等待客户端发送数据（第二次阻塞）；

4）如果客户端没有发送数据，那么服务端将会一直阻塞等待客户端发送数据。

服务端从启动到收到客户端数据的这个过程，将会有两次阻塞的过程：

  • 1）第一次在等待连接时阻塞；
  • 2）第二次在等待数据时阻塞。

BIO会产生两次阻塞，这就是BIO的非常重要的一个特点。

单线程BIO的缺陷

当我们的服务器接收到一个连接后，并且没有接收到客户端发送的数据时，是会阻塞在read()方法中的，那么此时如果再来一个客户端的请求，服务端是无法进行响应的。换言之：在不考虑多线程的情况下，BIO是无法处理多个客户端请求的

BIO如何处理并发

单线程版的BIO并不能处理多个客户端的请求，那么如何能使BIO处理多个客户端请求呢?

我们只需要在每一个连接请求到来时，创建一个线程去执行这个连接请求，就可以在BIO中处理多个客户端请求了，这也就是为什么BIO的其中一条概念是服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理。

【多线程BIO版本简易实现】

 package com.artisan.bio;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class ServerMultThread {

    public static void main(String[] args) {
        byte[] buffer = new byte[1024];
        try {
            ServerSocket serverSocket = new ServerSocket(1234);
            System.out.println("服务器已启动并监听8080端口");
            while (true) {
                System.out.println();
                System.out.println("服务器正在等待连接...");
                Socket socket = serverSocket.accept();
                new Thread(() -> {
                    System.out.println(Thread.currentThread().getName() + " 服务器已接收到连接请求...");
                    System.out.println();
                    System.out.println(Thread.currentThread().getName() + "服务器正在等待数据...");
                    try {
                        socket.getInputStream().read(buffer);
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "服务器已经接收到数据");
                    System.out.println();
                    String content = new String(buffer);
                    System.out.println(Thread.currentThread().getName() + "接收到的数据:" + content);
                }).start();

            }
        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

多启动几个客户端，测试结果如下

在这里插入图片描述

多线程BIO服务器的弊端

多线程BIO服务器虽然解决了单线程BIO无法处理并发的弱点，但是也带来一个问题：如果有大量的请求连接到我们的服务器上，但是却不发送消息，那么我们的服务器也会为这些不发送消息的请求创建一个单独的线程，那么如果连接数少还好，连接数一多就会对服务端造成极大的压力。

所以：如果这种不活跃的线程比较多，我们应该采取单线程的一个解决方案，但是单线程又无法处理并发，这就陷入了一种很矛盾的状态，于是就有了NIO

NIO

NIO要解决的问题

我们先来看看单线程模式下BIO服务器的代码，其实NIO需要解决的最根本的问题就是存在于BIO中的两个阻塞，分别是等待连接时的阻塞和等待数据时的阻塞

package com.artisan.bio;

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class Server {
    public static void main(String[] args) {

        // BIO 面向字节
        byte[] bytes = new byte[1024];

        ServerSocket serverSocket = null;
        try {
            serverSocket = new ServerSocket(1234);
            System.out.println("服务端已开启端口");

            while (true) {
                System.out.println();

                System.out.println("服务端等待连接......");

                Socket socket = serverSocket.accept();
                System.out.println("服务端已经收到连接请求");

                System.out.println("服务端等待数据.....");

                socket.getInputStream().read(bytes);
                System.out.println("服务端等已收到数据.....");

                String msg = new String(bytes);

                System.out.println("接收到了数据: " + msg);
            }

        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

如果单线程服务器在等待数据时阻塞，那么第二个连接请求到来时，服务器是无法响应的。如果是多线程服务器，那么又会有为大量空闲请求产生新线程从而造成线程占用系统资源，线程浪费的情况。

那么我们的问题就转移到，如何让单线程服务器在等待客户端数据到来时，依旧可以接收新的客户端连接请求。

模拟NIO

如果要解决上文中提到的单线程服务器接收数据时阻塞，而无法接收新请求的问题，那么其实可以让服务器在等待数据时不进入阻塞状态，问题不就迎刃而解了吗？

方案一： （等待连接时和等待数据时不阻塞）

package com.artisan.bio;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.nio.charset.Charset;

public class MyServer {

    public static void main(String[] args) throws Exception {
        ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
        try {
            //Java为非阻塞设置的类
            ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
            serverSocketChannel.bind(new InetSocketAddress(1234));

            //设置为非阻塞
            serverSocketChannel.configureBlocking(false);
            while (true) {
                SocketChannel socketChannel = serverSocketChannel.accept();
                if (socketChannel == null) {
                    //表示没人连接
                    System.out.println(Thread.currentThread().getName() + " 正在等待客户端请求连接...");
                    Thread.sleep(5000);
                } else {
                    System.out.println(Thread.currentThread().getName() + "当前接收到客户端请求连接...");
                }
                if (socketChannel != null) {
                    //设置为非阻塞
                    socketChannel.configureBlocking(false);
                    byteBuffer.flip();//切换模式  写-->读
                    int effective = socketChannel.read(byteBuffer);
                    if (effective != 0) {
                        String content = Charset.forName("utf-8").decode(byteBuffer).toString();
                        System.out.println(content);
                    } else {
                        System.out.println(Thread.currentThread().getName() + "当前未收到客户端消息");
                    }
                }
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

客户端测试代码

package com.artisan.bio;

import java.io.IOException;
import java.net.Socket;
import java.util.Scanner;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class ClientWithInput {
    private static Socket socket;
    private static Scanner sc;

    public static void main(String[] args) throws IOException {

        try {
            while (true) {
                socket = new Socket("127.0.0.1", 1234);
                String message = null;
                sc = new Scanner(System.in);
                message = sc.next();
                socket.getOutputStream().write(message.getBytes());
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            socket.close();
            sc.close();
        }
    }
}

在这里插入图片描述

在这里插入图片描述

在这种解决方案下，虽然在接收客户端消息时不会阻塞，但是又开始重新接收服务器请求，用户根本来不及输入消息，服务器就转向接收别的客户端请求了，换言之，服务器弄丢了当前客户端的请求。

方案二（缓存Socket，轮询数据是否准备好）

package com.artisan.bio;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.nio.charset.Charset;
import java.util.ArrayList;
import java.util.List;

public class MyServer {

    public static void main(String[] args) throws Exception {
        ByteBuffer byteBuffer = ByteBuffer.allocate(1024);

        List<SocketChannel> socketList = new ArrayList<SocketChannel>();
        try {
            //Java为非阻塞设置的类
            ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
            serverSocketChannel.bind(new InetSocketAddress(1234));
            //设置为非阻塞
            serverSocketChannel.configureBlocking(false);
            while (true) {
                SocketChannel socketChannel = serverSocketChannel.accept();
                if (socketChannel == null) {
                    //表示没人连接
                    System.out.println(Thread.currentThread().getName() + "正在等待客户端请求连接...");
                    Thread.sleep(5000);
                } else {
                    System.out.println(socketChannel.getRemoteAddress() + "当前接收到客户端请求连接...");
                    socketList.add(socketChannel);
                }
                for (SocketChannel socket : socketList) {
                    socket.configureBlocking(false);
                    int effective = socket.read(byteBuffer);
                    if (effective != 0) {
                        byteBuffer.flip();//切换模式  写-->读
                        String content = Charset.forName("UTF-8").decode(byteBuffer).toString();
                        System.out.println(socket.getRemoteAddress() + "接收到消息:" + content);
                        System.out.println();
                        byteBuffer.clear();
                    } else {
                        // System.out.println(socket.getRemoteAddress() + "当前未收到客户端消息");
                    }
                }
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

客户端我们使用如下代码去模拟

package com.artisan.bio;

import java.io.IOException;
import java.net.Socket;
import java.util.Scanner;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */
public class ClientWithInput {
    private static Socket socket;
    private static Scanner sc;

    public static void main(String[] args) throws IOException {

        try {
            while (true) {
                socket = new Socket("127.0.0.1", 1234);
                String message = null;
                sc = new Scanner(System.in);
                message = sc.next();
                socket.getOutputStream().write(message.getBytes());
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            socket.close();
            sc.close();
        }
    }
}

在这里插入图片描述

在这里插入图片描述

我们可以发现
1. 消息并没有丢失
2. server端并没有开启多线程来处理消息，均是在main线程

在解决方案一中，我们采用了非阻塞方式，但是发现一旦非阻塞，等待客户端发送消息时就不会再阻塞了，而是直接重新去获取新客户端的连接请求，这就会造成客户端连接丢失。

而在解决方案二中，我们将连接存储在一个list集合中，每次等待客户端消息时都去轮询，看看消息是否准备好，如果准备好则直接打印消息。

可以看到，从头到尾我们一直没有开启第二个线程，而是一直采用单线程来处理多个客户端的连接，这样的一个模式可以很完美地解决BIO在单线程模式下无法处理多客户端请求的问题，并且解决了非阻塞状态下连接丢失的问题。

方案二存在的问题

从刚才的运行结果中其实可以看出，消息没有丢失，程序也没有阻塞。

但是，在接收消息的方式上可能有些许不妥，我们采用了一个轮询的方式来接收消息，每次都轮询所有的连接，看消息是否准备好，测试用例中只是三个连接，所以看不出什么问题来，但是我们假设有1000万连接，甚至更多，采用这种轮询的方式效率是极低的。

另外，1000万连接中，我们可能只会有100万会有消息，剩下的900万并不会发送任何消息，那么这些连接程序依旧要每次都去轮询，这显然是不合适的。

NIO是如何解决这些问题的

在真实NIO中，并不会在Java层上来进行一个轮询，而是将轮询的这个步骤交给我们的操作系统来进行，他将轮询的那部分代码改为操作系统级别的系统调用（select函数，在linux环境中为epoll），在操作系统级别上调用select函数，主动地去感知有数据的socket

使用select/poll/epoll和直接在应用层做轮询的区别

NIO使用了操作系统底层的轮询系统调用 select/epoll(windows:select,linux:epoll)，那么为什么不直接实现而要去调用系统来做轮询呢？

select底层逻辑

假设有A、B、C、D、E五个连接同时连接服务器，那么根据我们上文中的设计，程序将会遍历这五个连接，轮询每个连接，获取各自数据准备情况，那么和我们自己写的程序有什么区别呢？

首先：我们写的Java程序其本质在轮询每个Socket的时候也需要去调用系统函数，那么轮询一次调用一次，会造成不必要的上下文切换开销。

而：Select会将五个请求从用户态空间全量复制一份到内核态空间，在内核态空间来判断每个请求是否准备好数据，完全避免频繁的上下文切换。所以效率是比我们直接在应用层写轮询要高的。

如果：select没有查询到到有数据的请求，那么将会一直阻塞（是的，select是一个阻塞函数）。如果有一个或者多个请求已经准备好数据了，那么select将会先将有数据的文件描述符置位，然后select返回。返回后通过遍历查看哪个请求有数据。

select的缺点：

  • 1）底层存储依赖bitmap，处理的请求是有上限的，为1024；
  • 2）文件描述符是会置位的，所以如果当被置位的文件描述符需要重新使用时，是需要重新赋空值的；
  • 3）fd（文件描述符）从用户态拷贝到内核态仍然有一笔开销；
  • 4）select返回后还要再次遍历，来获知是哪一个请求有数据。

poll的底层逻辑

poll的工作原理和select很像，先来看一段poll内部使用的一个结构体

struct pollfd{
    int fd;
    short events;
    short revents;
}

  • poll同样会将所有的请求拷贝到内核态，和select一样，poll同样是一个阻塞函数，当一个或多个请求有数据的时候，也同样会进行置位，但是它置位的是结构体pollfd中的events或者revents置位，而不是对fd本身进行置位，所以在下一次使用的时候不需要再进行重新赋空值的操作。

  • poll内部存储不依赖bitmap，而是使用pollfd数组的这样一个数据结构，数组的大小肯定是大于1024的。

解决了select 1、2两点的缺点。

epoll的底层逻辑

epoll是最新的一种多路IO复用的函数。这里只说说它的特点。

  • epoll和上述两个函数最大的不同是，它的fd是共享在用户态和内核态之间的，所以可以不必进行从用户态到内核态的一个拷贝，这样可以节约系统资源。

  • 另外，在select和poll中，如果某个请求的数据已经准备好，它们会将所有的请求都返回，供程序去遍历查看哪个请求存在数据，但是epoll只会返回存在数据的请求，这是因为epoll在发现某个请求存在数据时，首先会进行一个重排操作，将所有有数据的fd放到最前面的位置，然后返回（返回值为存在数据请求的个数N），那么我们的上层程序就可以不必将所有请求都轮询，而是直接遍历epoll返回的前N个请求，这些请求都是有数据的请求。

高性能网络编程 - select、 poll 、epoll 、libevent

在这里插入图片描述

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

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

相关文章

【NI-DAQmx入门】触发相关

【NI-DAQmx入门】触发相关

触发概述 触发采集为用户提供了两个主要好处&#xff1a;它对输入信号相对于触发事件进行计时&#xff0c;因此用户仅捕获感兴趣区域中的信号&#xff0c;从而节省硬件带宽和内存。 模拟触发和数字触发 模拟触发和数字触发的区别在于触发源的不同。数字触发是一种 TTL 信号&am…
阅读更多...
C++实现ransac

C++实现ransac

目录 一、ransac算法原理 1.1、算法概念 1.2、图解 二、c实现ransac 2.1、设置随机样本和离群点 2.2、随机抽取样本 2.3、内点计算 2.4、更新参数 2.2、完整代码 一、ransac算法原理 1.1、算法概念 随机抽样一致性 (RANSAC) 是一种迭代方法&#xff0c;用于根据一组包…
阅读更多...
225.用队列实现栈（LeetCode）

225.用队列实现栈（LeetCode）

思路 思路&#xff1a;用两个队列实现栈后进先出的特性 &#xff0c;两个队列为空时&#xff0c;先将数据都导向其中一个队列。 当要模拟出栈时&#xff0c;将前面的元素都导入另一个空队列&#xff0c;再将最后一个元素移出队列 实现 实现&#xff1a; 因为C语言没有库可以…
阅读更多...
【每日一题】—— D. Epic Transformation（Codeforces Round 710 (Div. 3)）（找规律+贪心）

【每日一题】—— D. Epic Transformation（Codeforces Round 710 (Div. 3)）（找规律+贪心）

&#x1f30f;博客主页&#xff1a;PH_modest的博客主页 &#x1f6a9;当前专栏&#xff1a;每日一题 &#x1f48c;其他专栏&#xff1a; &#x1f534; 每日反刍 &#x1f7e1; C跬步积累 &#x1f7e2; C语言跬步积累 &#x1f308;座右铭&#xff1a;广积粮&#xff0c;缓称…
阅读更多...
Linux socket编程(3):利用fork实现服务端与多个客户端建立连接

Linux socket编程(3):利用fork实现服务端与多个客户端建立连接

上一节&#xff0c;我们实现了一个客户端/服务端的Socket通信的代码&#xff0c;在这个例子中&#xff0c;客户端连接上服务端后发送一个字符串&#xff0c;而服务端接收到字符串并打印出来后就关闭所有套接字并退出了。 上一节的代码较为简单&#xff0c;在实际的应用中&…
阅读更多...
揭秘Vue中的nextTick：异步更新队列背后的技术原理大揭秘！

揭秘Vue中的nextTick：异步更新队列背后的技术原理大揭秘！

&#x1f3ac; 江城开朗的豌豆&#xff1a;个人主页 &#x1f525; 个人专栏 :《 VUE 》 《 javaScript 》 &#x1f4dd; 个人网站 :《 江城开朗的豌豆&#x1fadb; 》 ⛺️ 生活的理想&#xff0c;就是为了理想的生活 ! 目录 ⭐ 专栏简介 &#x1f4d8; 文章引言 一、N…
阅读更多...
解码方法00

解码方法00

题目链接 解码方法 题目描述 注意点 s 只包含数字&#xff0c;并且可能包含前导零计算并返回 解码 方法的 总数 解答思路 使用动态规划解决本题&#xff0c;其思路为&#xff1a;从后往前遍历字符串&#xff0c;遍历到任一i位置的字符c时&#xff0c;有几种情况&#xff1…
阅读更多...
react中间件的理解

react中间件的理解

一、是什么&#xff1f; 中间件&#xff08;Middleware&#xff09;在计算机中&#xff0c;是介于应用系统和系统软件之间的一类软件&#xff0c;它使用系统软件所提供的基础服务&#xff08;功能&#xff09;&#xff0c;衔接网络应用上的各个部分或不同的应用&#xff0c;能…
阅读更多...
ubuntu20安装opencv4和opencv_contrib 多版本共存

ubuntu20安装opencv4和opencv_contrib 多版本共存

openCV 卸载 openCV 安装后的源码尽可能保留&#xff0c;因为可以直接从build文件夹下卸载已经安装的openCV. 参考链接&#xff1a;视觉学习笔记10——opencv的卸载、安装与多版本管理 如果已经安装完openCV,后续想重新装&#xff0c;需要先卸载掉安装的openCV. 在ubuntu终端…
阅读更多...
离散卡尔曼滤波器算法详解及重要参数(Q、R、P)的讨论

离散卡尔曼滤波器算法详解及重要参数(Q、R、P)的讨论

公开数据集中文版详细描述参考前文&#xff1a;https://editor.csdn.net/md/?not_checkout1&spm1011.2124.3001.6192神经元Spike信号分析参考前文&#xff1a;https://blog.csdn.net/qq_43811536/article/details/134359566?spm1001.2014.3001.5501神经元运动调制分析参考…
阅读更多...
安防监控EasyCVR视频汇聚平台使用海康SDK播放出现花屏是什么原因？

安防监控EasyCVR视频汇聚平台使用海康SDK播放出现花屏是什么原因？

视频云存储/安防监控EasyCVR视频汇聚平台基于云边端智能协同&#xff0c;支持海量视频的轻量化接入与汇聚、转码与处理、全网智能分发、视频集中存储等。音视频流媒体视频平台EasyCVR拓展性强&#xff0c;视频能力丰富&#xff0c;具体可实现视频监控直播、视频轮播、视频录像、…
阅读更多...
《洛谷深入浅出进阶篇》P3397 地毯————二维差分

《洛谷深入浅出进阶篇》P3397 地毯————二维差分

上链接&#xff1a;P3397 地毯 - 洛谷 | 计算机科学教育新生态 (luogu.com.cn)https://www.luogu.com.cn/problem/P3397 上题干&#xff1a; 题目描述 在 nn 的格子上有 m 个地毯。 给出这些地毯的信息&#xff0c;问每个点被多少个地毯覆盖。 输入格式 第一行&#xff0c;两个…
阅读更多...
Git | Git的基本操作以及原理介绍

Git | Git的基本操作以及原理介绍

文章目录 基本操作创建git仓库配置name和email .git目录的结构git add & git commit.git目录结构的变化 git追踪管理的数据git的版本回退回退的原理回退的三种情况 版本库中文件的删除git分支管理分支的删除合并分支时的冲突分支的合并模式分支策略git stash不要在master分…
阅读更多...
实用篇-ES-DSL操作文档

实用篇-ES-DSL操作文档

一、mapping属性 mapping属性的官方文档: https://elastic.co/guide/en/elasticsearch/reference/current/index.html 下面的表格是介绍elasticsearch中的各个概念以及含义&#xff0c;看的时候重点看第二、三列&#xff0c;第一列是为了让你更理解第二列的意思&#xff0c;所…
阅读更多...
嵌入式养成计划-54----ARM--异常处理流程

嵌入式养成计划-54----ARM--异常处理流程

一百三十五、异常处理流程 135.1 arm处理器工作模式 135.2 异常源和异常模式关系 135.2.1 异常源 异常源就是引发处理器进入相应异常模式 135.2.2 对应关系 异常模式异常源FIQ模式FIQ类型异常源引发处理器进入FIQ模式IRQ模式IRQ类型异常源引发处理器进入IRQ模式SVC模式上电…
阅读更多...
三、Eureka注册中心

三、Eureka注册中心

目录 一、作用及调用方式 二、搭建eureka注册中心 三、注册user-service和order-service 四、新增实例 五、服务拉取 六、总结 一、作用及调用方式 在服务提供者启动时&#xff0c;它会向eureka注册中心提供自己的信息&#xff0c;并每30秒进行一次刷新eureka注册中心保存…
阅读更多...
14——2

14——2

这道题目前面看不懂可以看比如后面的 这里1/3是因为S100的长度n3&#xff08;100占3位&#xff09;&#xff0c;然后1出现的占比是1/3&#xff08;1在第一位&#xff09;&#xff0c;0出现的占比是2/3&#xff0c;因为0出现了2次&#xff0c;&#xff08;第二位&#xff0c;第…
阅读更多...
【文章学习系列之模型】DAGMM

【文章学习系列之模型】DAGMM

本章内容 文章概况模型结构损失函数实验结果实验分析总结 文章概况 《Deep Autoencoding Gaussian Mixture Model for Unsupervised Anomaly Detection》是2018年发表于ICLR的一篇论文&#xff0c;该论文提出一种端到端的无监督异常检测方法DAGMM&#xff0c;取得了不错的效果…
阅读更多...
3.3 Linux 文件管理

3.3 Linux 文件管理

1、查看系统信息 tty 命令 描述&#xff1a;查看当前系统在哪个终端语法&#xff1a;tty Linux默认情况下提供6个虚拟终端来让用户登录&#xff0c;系统将F1~F6定义为tty1~tty6。 ctrlalt(F1~F6) &#xff1a;从图形界面切换到命令行界面的第 n 个虚拟终端&#xff08;F1 是…
阅读更多...
社区牛奶直供站：创新供应链，满足消费者需求

社区牛奶直供站：创新供应链，满足消费者需求

社区牛奶直供站&#xff1a;创新供应链&#xff0c;满足消费者需求 社区牛奶直供站模式彻底改变了传统的多级经销链条和流通加价环节&#xff0c;通过削减中间环节&#xff0c;以相对低价直接供应牛奶给消费者。这样做实现了从奶企源头直接供应到社区家庭的目标&#xff0c;精准…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023