最近发现自己的回溯算法，图论相关完全是一坨狗屎，遂记录一下 46. 全排列给定一个不含重复数字的数组 nums ，返回其 所有可能的全排列 。你可以 按任意顺序 返回答案。 示例 1： 12输入：nums = [1,2,3]输出：[[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]] 12345678910111213141516171819202

连接二进制表示可形成的最大数值给你一个长度为 3 的整数数组 nums。 现以某种顺序 连接 数组 nums 中所有元素的 二进制表示 ，请你返回可以由这种方法形成的 最大 数值。 注意 任何数字的二进制表示 不含 前导零。 想到了一点排序，但是不知道怎么排，就暴力做了，很蠢的先把每个数转化为二进制字符串，再依次连接比较大小 1234567891011class Solution {

基础数据结构SDSSimple Dynamic String，简单动态字符串，由于C语言内置的字符串底层是字符数组，有诸多不爽的点：二进制不安全（读取时以\0结尾，若字符串本身带有\0字符，则读到这个字符就结束了）、不能动态扩容（就像Java的String一样，不可变）、获取字符串长度需要遍历到结束字符。 所以Redis的作者做了些许改进，自定义了SDS结构，Header存储字符串长度，申请的内存

概述在一个Service中含有事务的方法里调用另一个Service有事务的方法时，此时BService中的事务被传播到了AService，这就是事务的传播 12345678910111213@Servicepublic class AService { @Autowired private BService bservice; @Transanction

简介WebSocket 是一种计算机通信协议，为 Web 应用程序提供了全双工通信通道。它是为了克服 HTTP 协议的一些局限性而设计的，特别是 HTTP 是单向的——客户端请求，服务器响应。在 WebSocket 连接中，客户端和服务器之间的通信是持续的，可以相互发送消息，而不必每次都重新建立连接。 握手过程: WebSocket 连接从 HTTP 请求开始，客户端发起一个 HTTP 请求到服务

TCP ACK 始终表示接收方期望收到的下一个字节序号，而 SEQ 表示发送方当前发送数据段的字节序号。 全连接队列 (Accept Queue)存储已经完成三次握手并建立的 TCP 连接，但还没有被应用程序 accept() 调用接收的连接。 当 TCP 连接建立成功后，三次握手完成，连接就被放入全连接队列中，等待服务器应用程序调用 accept() 来取出这个连接。连接一旦从全连接队列中取出

快速排序123456789101112131415161718192021222324252627282930public static void main(String[] args) { int[] nums = {5, 7, 3, 1, 9, 6, 4, 2, 8}; quick_sort(nums, 0, nums.length - 1);

前言本文是对一年前学的伯克利的CS61B课程的project2：gitlet项目的一次回顾和总结，github连接 Gitlet总体介绍Gitlet是UCB CS61b课程中的一个项目，实现了简化版的git，支持add，commit，log，checkout，merge等操作。git是一个分布式的版本控制工具，如果想要了解更多的git知识，请点击git官网查看。 Gitlet原理原理上gitlet

阿里云获取服务首先进入此链接短信服务 按照如下图的快速学习一步一步走完即可，其中系统设置可以不管 签名：短信开头的发信人信息，如【中国移动】 模板：短信内容，如 您的验证码为：${code}，该验证码5分钟内有效，请勿泄露于他人！ 购买套餐云通信精选特惠这个链接有200条2元的套餐，测试学习必备 导入依赖12345678910<dependency> <groupId

项目通过docker compose部署上线时，出现了容器疯狂重启的情况，昨天是nacos不断挂掉重启，连带着seata也一直重启，排查发现是内存不足的原因，重新分配内存后得以解决。 今天seata和Sentinel又开始了，我寻思内存已经够用了啊，nacos都没事了，怎么这两个又出问题了，搜索一番终于解决，记录一下原因和解决方案。 错误信息使用docker logs seata查看日志，只有一行