- 博客(24)
- 收藏
- 关注
RSS订阅原创 从一个编辑校验问题谈接口设计的边界
都是这个2乘2的状态内在的矛盾去发散开来的。重点是我们如何发现这种内在的矛盾。这样解决破坏了这种机制的什么东西。唯一判断的基础建设。你只能利用一个根据城市名查询相关记录是否存在的方法。且你不能要求新增其他的数据库交互手段以及和前端的动作。当输入到语义的映射不可逆时，不存在完备校验函数。层尽可能通过一个接口，一个方法来解决。奇怪的校验（城市和图片配置的校验）状态空间的维度 < 语义空间的维度。证明检查语义坍缩说明矛盾的机制？异常（不发生数据库变更）的。违反了自反推导的命题和状态。这是一个“非函数性问题”
2025-12-13 21:02:10
762
原创 并发考古二（可见性）
我才确定了可靠的关键在于操作同步的反馈和持久化技术的写入。而在非顺序机器中，相当一部分事件之间不可比，我们判断的是一种类似“机械结构传导”的关系——也就是说，我们通过观察传播、延迟、确认这些外部证据来推断顺序，而非通过运算本身。这种不可比性本质上与“最终一致性”有某种形而上的共性：我们讨论的不是严格的先后，而是“何时认为状态已经稳定”。我们知道现代的编程语言提供了原子操作这样的方式来确保某些原子操作的变量的可靠性。真正让我看到偏序价值的，是一个看似简单的时延处理问题——在本地运算与传输之间的取舍。
2025-11-17 23:34:33
686
原创 考古并发历史（1）
在顺序机器中，比较事件之间全序（total order）；然后还有就是当时这个算法的提出是没有考虑死锁。算法他自己也强调了两个前提即对称和循环。引入顺序，使每个进程在尝试进入临界区时。而这个维护轮次的变量是安全的吗？在非顺序机器中，比较事件之间不可比；的或者说这个假设的场景太过于理想。Dekker 算法（1959）一次只有一个进程可以进入临界区。按照固定顺序检查前面的进程。
2025-10-26 21:06:14
280
原创 读读线程池的代码
我们要关注的是钩子是怎么触发的？而在liunx中的epoll所谓的事件驱动则和一些驱动层的信号紧密相关。而netty难学就难在你在应用层编码的每个任务的提交时机和触发时机并非像线程池那样明确都是不确定的。某种程度上这种依赖于方法签名决定类型而非手动声明类型的写法与泛型和函数式的用法有深刻的关系。这个是因为callable要考虑返回的类型所以要求这边泛型声明以支持返回不同类型的返回结果。返回值的存在与否 + 方法参数类型，共同决定了 Lambda 实现的是 Runnable 还是 Callable。
2025-10-07 20:23:13
852
原创 springboot源码学习。（SPI和自动装配）
起因事情的起因是这样的题主最近在研究spring amQP 的源码有个博主写的特别好我在这里面其实看到不少熟悉的知识点。这里就是spring自动装配的流程，其完整流程就是SpringBoot启动->@SpringBootApplication->@EnableAutoConfiguration->AutoConfigurationImportSelector扫描META-INF/spring.factories->加载RabbitAutoConfiguration->创建RabbitMQ相关Bean。
2025-09-06 00:36:14
735
原创 jdk1.8 nio相关。java对象和epoll三大函数怎么关联的？（有点乱有点跳）
SelectableChannel的每个子类都定义了一个validOps（）方法，该方法返回一组标识通道支持的操作的集合。（tip， 我们讨论流的时候不要狭隘的认为是一种传统的字节流。我们可以看到实现这个抽象类的两个类是两个mpl 还有一个带有明显的windowsselectorProvider相关的类。注意这里是mpl和上文的windowmpl是一个层级和windowprovider相关的类是不相属的。我们追入一程可以看到是当前的selctroprovidew的provider相关的方法只返回的。
2025-07-13 13:09:58
461
原创 更一段不这么顺利的ai开发经历
好久没有发博客了。找工作老是失败，想着没什么核心竞争力。就单纯的结合业务场景做几个方案设计。然后技术上不精进，只是在设计表和一些上下游的缝合上 投入大量的精力不知道怎么去提升。对于一个已经接不到什么比较有商业价值和表现价值的题主来说。要么自己动手去diy一个产品自己打通上下游。要么就是卷些纯技术的东西才能够让自己安点心。故事的起因的是这样。6月份感觉了暑期实习都快找完了。我也陆陆续续也有面几家。但是我感觉都是kpi面。属于那种聊的挺开始的时候流程也没挂但是就是一直在被拖流程。所以题主有点愤怒。想到既然公司可
2025-06-27 23:18:42
281
原创 tomcat的websocket协议升级。如何从报文交换变成全双工通信？session对象的注册和绑定？
get/setDefaultMaxSessionIdleTimeout() 设置 WebSocket 会话的最大空闲时间（毫秒）get/setDefaultMaxBinaryMessageBufferSize() 设置默认二进制消息的缓冲区大小（字节）get/setDefaultAsyncSendTimeout() 设置异步发送消息的最大等待时间（毫秒）来实现异步操作的结果等待（阻塞等待），从而兼顾了非阻塞 I/O 和流程控制的需求。）WebSocket POJO，交由容器（Tomcat）自己去实例化它。
2025-06-10 11:44:35
897
原创 io多路复用的三种方式
所以本质epoll相对于poll和select最大的优势还是省下那个对文件描述符轮询的资源和一个搜索上的数据结构的优化。因为 epfd1 发生事件了，epfd2 会被唤醒，epoll_wait 返回，告诉你 epfd1（你看到的数字5，就是 epfd1 的文件描述符）发生了事件。可以看到获取文件描述符的过程是不会阻塞的。所以这个文件描述符的状态是一个维护在vfs中的。我们可以看看到不同于poll使用封装的poll_fd及对应的List select直接用一个fd_bits相关的数据结构来表示文件描述符。
2025-06-05 10:31:16
977
原创 网络研究角度下的文件系统（学习）
VFS文件系统题主本来的初衷是研究netty而去研究liunx的部分源码。所以在研究到vfs文件系统的话如果从流和通信这些可靠性的讨论似乎就已经到了尽头了。无非是看下数据结构。然后上层统一的暴漏了什么样的接口。并不值得成文。所以题主在看在学的时候一直在思考如何去描述这么一个事物。市面上对于文件系统的描述几乎都是侧重于说明文件系统的寻址算法或者文件系统在操作系统层面的抽象。都不能够让我比较满意。我本身对于复杂的寻址算法本身不感兴趣。也对抽象那一套所谓的拆分和中间层，提升复用性的思路不感冒。
2025-05-29 10:58:15
638
原创 文件系统与反思（随笔）
回到开篇的引子，可能连我自己觉得第一句话读上去有点拽拽的感觉除此之外沉思过后，就会去想，为什么可接发达这个大家都能够说的明白的事实，还要想茴香豆的写法那样，刻意的去刁钻和为难？题主有记日志的习惯，对于市面上各种各样的文档工具由于工作的原因总能接触到，但是随着需求的提升，我希望一个日志里面能够有图片能够有文件。能够协作和格式传输。但是当我换位思考的时候，我才发现本质上我需要一种支持通用文件传输（word pdf txt png）和保存和管理软件的时候的开发时，我意识到了自己不是需要一个所谓个人数据库的概念。
2025-05-21 16:22:35
469
原创 linux 流是可靠的吗？内核有对串口通信做可靠性的保障吗？liunx源码调试以及对串口数据从环形缓冲区到编码全链路分析。
题主在读大一的时候那会由于家里的原因，曾把学习的重心放在单片机上。说来惭愧，刚接触技术。很多步骤都只能按部就班。不了解通信原理，也不了解什么参数的数据含义。照着网上的代码一顿乱写。然后不断测试调整，勉强还看的过去。当时又有恐学之疑。害怕自己进度太慢？害怕自己学了好久好久一事无成？跟着视频勉强把该跑的几个模块跑通之后，由于学校资源的问题，便跑去学那java，前后端那些东西了。当时物理现象总是不可靠的。
2025-05-20 12:00:43
711
原创 liunx源码探索。文件描述，流，tty,UART,port,dirver
Linux 中“文件”（“文件描述符”）和“流”的行为之所以一致，是因为 Linux 内核在驱动层（tty）实现流行为的时候已经关联了文件结构体。这些功能主要由 drivers/tty/n_tty.c 文件中的 n_tty_ldisc_ops 结构体实现，该结构体定义了一系列操作函数，用于处理上述功能。所以流的有效性和可靠性是依赖于tty的tty和设备中间的行为又是依赖于uart的也就是说本质上是uart协议保证了流的有效性。上网查了下，这边给出来的判断是通过一个seek 的行为去区分的。
2025-05-16 00:28:56
1046
原创 镜像的创建方法(收尾)
题主这边想趁热打铁想对Liunx这一快的io模型和网络这部分的东西再像一段功夫。在学习这些源码的过程中。但是越研究越是对lilunx和一些现代容器编排工具的设计感概其精妙。我这边源码看的也差不多了。网络部分的东西就不好放了。因为大量的图片和敏感信息这边做起处理来太累了。：在 Kubernetes 集群中安全构建镜像的工具，不依赖 Docker Daemon。但容器中原始的服务主进程（通常是 PID 1），它的环境变量在容器创建时就固定了。你启动的是一个新的 shell 进程，它拥有自己的环境变量副本。
2025-05-14 11:46:03
348
原创 容器信息与容器指令的实现。
因此，需要在这段C代码前面一开始的位置就指定环境变量，对于不使用exec功能的Go代码，只要不设置对应的环境变量，那么当C程序检测到没有这个环境变量时，就会直接退出，继续执行原来的代码，并不会影响原来的逻辑。可以看到，这段程序还是很怪异的，和普通的Go代码是不一样的。这里主要使用了构造函数，然后导入了C模块，一旦这个包被引用，它就会在所有Go运行的环境启动之前执行，这样就避免了Go多线程导致的无法进入mnt Namespace的问题。所以在docker也好更成熟的商业的应用就需要对这方面做更严谨的处理。
2025-05-10 13:08:42
566
原创 容器后台托管以及生命周期管理（回收）
在Docker早期版本，所有的容器init进程都是从docker daemon这个进程fork出来的，这也就会导致一个众所周知的问题，如果docker daemon挂掉，那么所有的容器都会宕掉，这给升级docker daemon带来很大的风险。这就是父进程退出而容器进程依然运行的原理。虽然容器刚开始是由当前运行的mydocker进程创建的，但是当mydocker进程退出后，容器进程就会被进程号为1的init进程接管，这时容器进程还是运行着的，这样就实现了mydocker退出、容器不宕掉的功能。
2025-05-07 22:06:01
958
原创 容器初始化（根路径重定向以及内存文件系统挂载）
pivot_root（解除根路径依赖）在编写应用时，我们经常会涉及路径依赖，比如读取配置文件、写日志、加载资源等。这些路径通常是相对于根目录（）或某个固定路径写死的。当应用运行在容器环境中时，为了让这些路径操作不会访问宿主机的文件系统，我们需要“切换”进程所看到的根目录。这个时候，就需要用到rootfs的操作 —— 也就是通过pivot_root系统调用来改变进程的根文件系统。pivot_root的作用是将当前进程的根目录切换为指定的新根目录new_root，并将旧的根目录移动到。
2025-05-06 21:55:48
847
原创 通过系统调用实现进程隔离？（初学用）
接着，使用 cmd.SysProcAttr 来设置进程的命名空间标志，如 CLONE_NEWUTS、CLONE_NEWPID、CLONE_NEWNS、CLONE_NEWNET 和 CLONE_NEWIPC，这些标志确保容器内的进程能够创建并隔离所需的命名空间，保证进程的资源不与宿主机共享。它会继承父进程的环境，包括文件描述符、内存映像等，这样有时会导致子进程继承父进程的资源，可能不适用于隔离环境（比如容器化的需求）。可以完全替换当前进程的映像，使得新的进程与父进程完全隔离，避免了不必要的资源继承。
2025-05-01 12:36:53
1010
原创 Nignx 负载均衡能否解决公网宽带问题？关于nginx 七层和四层负载的抓包实验
我们现在一个虚拟机中跑一个nc 命名来模拟一个http服务器发一个请求然后手写一个请求头成功测试到我们的http服务器返回了数据。
2025-04-14 13:47:28
252
原创 容器进程行为（交互）
后台进程通常是脱离终端独立运行的，标准流（stdout、stderr）可能会被重定向或者丢失，从而使得 Docker 守护进程在管理容器时无法及时响应容器状态的变化，影响容器的监控和管理。在传统的操作系统中，前台进程是与终端紧密关联的，它通常与用户进行实时交互，直接影响用户的操作体验。终端关闭时，操作系统会将该终端的状态更改为“已关闭”，此时，系统会发送 SIGHUP 信号给该终端上的所有进程。：通过它，原本的进程启动变成了一个带有“封装”的进程启动，它确保进程脱离会话，且重定向输出，不受终端关闭影响。
2025-04-02 11:20:16
954
原创 容器网络以及tcp抓包实验
你可以获取该网络的名称、ID、网络驱动类型、配置的子网、网关信息，以及连接到该网络的容器。它实现了网络命名空间之间的通信，并通过将虚拟网络接口（veth）桥接到宿主机或容器之间，提供了隔离但可通信的网络环境。: 当前连接到此网络的容器信息，包含容器的名字、ID、网络地址（如 IPv4 或 IPv6 地址）、MAC 地址等。它显示了接收到的和发送的数据包，表明容器有活动的网络通信。比如容器、镜像、网络等的信息。设备，并将其中一个端点放置在宿主机的网络命名空间中，另一个端点则放置在容器的网络命名空间中。
2025-03-17 19:32:43
564
原创 Cgroup 和容器 实践（学习）
为了有效管理大量的进程和机器，谷歌开发了一个内部的资源管理系统，目的是确保每个进程或任务能够获得一定的资源配额，同时避免进程之间的资源竞争。如果我们能够对每个服务或进程进行合理的资源限制，尤其是对内存和 CPU 的限制，那么就能有效避免系统级 OOM 错误的触发。例如，当容器的 CPU 使用率很高时，可以通过修改 cgroup 中的 CPU 配额来限制其 CPU 使用，或者在容器内存使用率达到上限时，通过调整内存限制来避免容器崩溃。会在容器启动时设置容器的资源限制（例如 CPU、内存的限制等）。
2025-03-14 18:51:33
1132
原创 区分名称空间和联合文件系统（初学）
每个联合文件系统的层叠结构是独立的。每个容器的文件系统是由其所属的联合文件系统提供的，即使容器运行在同一台宿主机上，它们的文件系统视图依然是互不影响的。当这些文件系统被挂载到宿主机时，它们的挂载路径是独立的，即使它们在宿主机的底层共享相同的物理存储，文件系统本身也是独立的。在容器A和容器B中，如果使用不同的联合文件系统和不同的 Mount Namespace，它们各自只能看到属于自己容器的文件系统层，无法互相访问对方的文件。它提供了一个抽象的文件系统视图，每个容器看到的文件系统是由只读层和可写层组成的。
2025-03-12 11:07:26
713
原创 名称空间隔离化实践（初学用）
每个进程在某个名称空间内运行时，会看到自己的资源视图（如网络接口、文件系统等），而其他名称空间中的进程看到的是不同的资源视图。Linux内核团队发现，容器技术需要将一个进程组的资源（如进程ID、文件系统、网络接口等）隔离起来，使得这些进程组能够像在独立的虚拟机中一样运行，但同时又不需要为每个容器创建一个完整的虚拟机。每个名称空间内的进程只能访问该名称空间内的资源。：你依然看到的是容器的文件系统，但 Docker 会进一步封装一些管理功能，如容器内的文件系统层次、容器内的 PID 命名空间等。
2025-03-11 16:14:54
635
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人