next

转自： https://blog.csdn.net/dog250/article/details/105756168 大约10年前，我写过两篇关于Linux内核CFS调度器的文章： https://blog.csdn.net/dog250/article/details/5302865 https://blog.csdn.net/dog250/article/details/5302864 我觉得这两篇文章是垃圾，但我又不删，留着给自己喷吧！ 不就是一个内核参数 kernel.sched_child_runs_first 吗？在今天看来，验证它是否起作用实在太简单了。 首先解释一下 为什么要子进程先运行 。 因为fork的行为造成了后续的COW(copy on write)，一般而言子进程会调用exec而替换掉需要COW的地址空间，子进程先运行可以避免不必要的COW开销。 那么对于CFS调度器而言，kernel.sched_child_runs_first是否有作用呢？我们试一下便知道，依然使用那两篇垃圾文章中的例子： #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> int main(int argc,char *argv[]) { int v = atoi(argv

上一篇笔记主要是一些常用方法和相关联的方法的总结，这一篇主要记录一下迭代器相关逻辑。 数组列表的迭代器是由于集合接口继承迭代器接口决定的，迭代器接口这里就不再重复了，有记录： 迭代器接口 。集合类都会有返回迭代器的方法： /** * 以正确的顺序返回此列表中元素的迭代器。 * <p> The returned iterator is <a href="#fail-fast"><i> fail-fast </i></a> . * @return an iterator over the elements in this list in proper sequence */ public Iterator< E > iterator () { return new Itr() ; //创建一个对象，具体逻辑在内部类中 } 迭代器方法的具体实现在 AbstractList 类中已经给出了，不过其子类型的实现细节，也就是 Itr 这个内部类会有所不同。 /** * An optimized version of AbstractList.Itr 相比较 AbstractList.Itr 这是个优化版本 */ private class Itr implements Iterator< E > { int cursor ; // index of next element to return

一、下载MySQL数据库并进行安装和配置 二、下载JDBC 下载地址 ： https://dev.mysql.com/downloads/connector/j/5.1.html 三、创建java项目，导入.jar包 四、测试访问数据库 1.使用JDBC API 连接和访问数据库，一般分为以下5个步骤 (1)加载驱动程序 (2)建立连接对象 (3)创建语句对象 (4)获得SQL语句的执行结果 (5)关闭建立的对象，释放资源 2.例如下面访问数据库的代码 （1）首先使用Navicat连接MySQL数据库，并在localhost新建如下图所示的数据库和表 特别注意 （2）在IDEA中新建类，并编写如下的程序 import java.sql.* ; public class MySQLDemo { public static void main(String[] args) throws Exception{ // 加载数据库驱动程序 try { Class.forName( "com.mysql.cj.jdbc.Driver" ); } catch (ClassNotFoundException cne){ cne.printStackTrace(); } String dburl = "jdbc:mysql://127.0.0.1:3306/webstore?&useSSL

# Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # units are case insensitive so 1GB 1Gb 1gB are all the same. ################################## INCLUDES ###################################

利用vue做的后台管理系统是单页面系统，当你想实现刷新的功能通常有以下几个方法： (1)window.location.reload() 　　这个是原生js中提供的一种刷新方法，用于刷新当前文档。 (2)this.$router.go(0) 　　vue-route提供的一种方法，在history记录中前进或者后退val步，当val为0时刷新当前页面。 　　以上两种方法，用的人都知道，这两种方法都类似于浏览器上的刷新页面按钮。回导致页面出现短暂的闪烁（重新加载页面），虽然简单粗暴，但是用户体验极差。 　　其实，局部的刷新就是小组件之间的刷新。最多的刷新场景就是对table列表中某条数据打开dialog框进行增删改之后刷新table的操作。这种可以每个页面都单独写好一个查询表格的公共的方法，在mounted周期的时候可以调用用于页面打开的时候默认展示table数据，需要的时候也可以调用用于刷新table数据。或是考虑以下两种方法，但是以下两种方法其实也是依靠mounted这个钩子函数来进行刷新的，只是少声明了一个公共方法而已。 (3)先跳转到一个空白组件，在跳转回原组件，触发钩子函数重新渲染达到刷新的目的。 首先，先定义一个空白组件： <template> <div></div> </template> <script> export default { data() { return

主要是贴代码 给自己做个总结（连接服务端初始化以及处理）： 1. NioEventLoop 用来正真处理io连接的 2.NioEventLoopGroup 可以简单的理解为处理组一共两个，一个是接受连接的，一个是处理连接的，里面的chooser即是NioEventLoop数组 服务端初始化流程 入口 ChannelFuture f = b.bind(8888).sync(); public ChannelFuture bind(int inetPort) { return this.bind(new InetSocketAddress(inetPort)); } public ChannelFuture bind(SocketAddress localAddress) { this.validate(); if (localAddress == null) { throw new NullPointerException("localAddress"); } else { return this.doBind(localAddress); } } private ChannelFuture doBind(final SocketAddress localAddress) { //初始化即注册 final ChannelFuture regFuture = this

接触C6000DSP不久，碰到没有直接例程的我像无头苍蝇一样乱找资料，由于大多数资料是英文的，且专有名词很多，理解起来十分费劲。但后来发现，真的是读书千遍，其义自见。多读几遍，特别是各个文档联系起来，头脑中有概念后，就越读越通顺了。 在此，用第一篇博客记录一下这几天的折腾，也希望可以为遇到同样问题的同学提供一些思路，大神请自动绕道。 废话结束。 需求：DSP作为主机，SRIO的DIO模式到FPGA，需要DSP读/写完成后产生中断。 再废话一句：大多数关于SRIO的中断介绍都是DOORBELL的，不适用于本例，所以越发使人焦躁。 解决问题的思路是通读文档后，参考TI的资料，尤其是要充分使用K1_STK_v1.1中的例程。 再有就是多看TI的论坛，有时中文论坛帮助更大些。 （特别感谢Brighton Feng大神的例程/论坛留言） 首先，要确定这个需求是可以被实现的，因为SRIO例程里并没有，所以千万别误会这个不可实现。SRIO user guide[1] 2.3.9.1.1短短一节，提到： Using the direct I/O protocol, once the single or multipacket data transfer is complete, the external PE, or the peripheral itself, needs to notify

前言 if...else 是所有高级编程语言都有的必备功能。但现实中的代码往往存在着过多的 if...else。虽然 if...else 是必须的，但滥用 if...else 会对代码的可读性、可维护性造成很大伤害，进而危害到整个软件系统。现在软件开发领域出现了很多新技术、新概念，但 if...else 这种基本的程序形式并没有发生太大变化。使用好 if...else 不仅对于现在，而且对于将来，都是十分有意义的。今天我们就来看看如何“干掉”代码中的 if...else，还代码以清爽。 问题一：if...else 过多 问题表现 if...else 过多的代码可以抽象为下面这段代码。其中只列出5个逻辑分支，但实际工作中，能见到一个方法包含10个、20个甚至更多的逻辑分支的情况。另外，if...else 过多通常会伴随着另两个问题：逻辑表达式复杂和 if...else 嵌套过深。对于后两个问题，本文将在下面两节介绍。本节先来讨论 if...else 过多的情况。 1 if (condition1) { 2 3 } else if (condition2) { 4 5 } else if (condition3) { 6 7 } else if (condition4) { 8 9 } else { 10 11 } 通常，if...else 过多的方法，通常可读性和可扩展性都不好

在上一讲中，我们已经完成了一个完整的案例，在这个案例中，我们可以通过Angular单页面应用（SPA）进行登录，然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中，我们会讨论在当前这种架构的应用程序中，如何完成用户授权。 回顾 《 Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权（一） 》 《 Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权（二） 》 《 Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权（三） 》 用户授权简介 在继续分析我们的应用程序之前，我们简单回顾一下用户授权。在用户登录的过程中，系统首先确定当前试图登录的用户是否为合法用户，也就是该用户是否被允许访问应用程序，在这个过程中，登录流程并不负责检查用户对哪些资源具有访问权限，反正系统中存在用户的合法记录，就认证通过。接下来，该用户账户就需要访问系统中的各个功能模块，并查看或者修改系统中的业务数据，此时，授权机制就会发挥作用，以便检查当前登录用户是否被允许访问某些功能模块或者某些数据，以及该用户对这些数据是否具有读写权限。这种决定用户是否被允许以某种方式访问系统中的某些资源的机制，称为授权。 最常见的授权可以基于用户组

说到ASP.NET CORE 管道模型不得不先来看看之前的ASP.NET 的管道模型，两者差异很大，.NET CORE 3.1 后完全重新设计了框架的底层，.net core 3.1 的管道模型更加灵活便捷,可做到热插拔，通过管道可以随意注册自己想要的服务或者第三方服务插件. ASP.NET 管道 请求进入ASP.NET 工作进程后，由进程创建HttpWorkRequest 对象，封装此次请求有关的所有信息，然后进入HttpRuntime 类进行进一步的处理。HttpRuntime 通过请求信息创建HttpContext 上下文对象，此对象将贯穿整个管道，直到响应结束。同时创建或从应用程序池里初始化一个HttpApplication对象，由此对象开始处理之前注册的多个HttpModule。之后调用HandlerFactory 创建Handler处理程序，最终处理此次请求内容，生存响应返回。 以前的管道模型是全家桶方式，所有的管道不支持热插拔，一次性全部集成在里面，所有这也是ASP.NET 没有.NET CORE 性能好的一大原因所在。 IHttpModule 和IHttpHandler 已经不复存在了，取而代之的是一个个中间件（Middleware）。Server将接收到的请求直接向后传递，依次经过每一个中间件进行处理，然后由最后一个中间件处理并生成响应内容后回传