前一两个月，老板召集大家开了个会，给我们发了两本书： 在没打开这两本书之前，容我来猜测一下大家心里的想法： 老板又来给我们洗脑了，这次换了一种新的手段 这是资本主义剥削劳动者的手段 这是在荼毒我们打工者的的思想，让我们一辈子打工 这些都是毒鸡汤 形式主义 等等。。。 我先看的是< > 这本书，后来通过这本书了解到了< > ；在读完< > 这本书以后，我体会最深的一句话：人性是复杂的，不是简单的黑与白，整本书围绕着这句话展开了任总灰度理论的解释和应用，从而告诉大家，华为就是这么一步步走过来的。 虽然成功不可复制，但是成功的方法我们可以学习；看完这本书以后，我不禁从内心里发出感叹：感谢老板对我的馈赠！他是我的人生导师之一！一个人思维的贫穷才是真正的贫穷，所以只有从本质上改变自己的思维方式，才有可能真正的成长。和华为相关的书我也读过不少，但是这本书确实挺有意思；这是一本能够帮助企业和个人成长的书籍。 < >整本书分为以下模块进行介绍 1、华为的四个成长的重要阶段 2、华为团队管理核心理念精髓 3、灰度用人之法 4、灰度的评价 5、灰度高效组织体系 6、灰度选拔 7、灰度分钱：打破黑和白两个极端 1、什么是灰度文化？ 灰度文化概括思维导图： 2、华为团队管理核心理念精髓 本章思维导图： 3、华为灰度用人之法 本章思维导图： 4、华为灰度的评价 本章思维导图： 5、华为灰度高效组织体系 本章思维导图： 6、华为灰度选拔 本章思维导图： 7、华为灰度分钱：打破黑和白两个极端 本章思维导图： 个人心得感想 为什么要有企业？企业的目的和本质又是什么？ 企业是组织众多个人开展经济活动的一种方式，而公司是企业的组织形式。 目的：盈利 本质：代替市场交易机制的另外一种治理模式。 这种治理模式实质上是一种经济活动，经济活动通过价格机制来协调，而企业通过内部的协调来代替经济活动，从而让企业有可持续的超额的利润回报。 从这本书中不止一次提到的奋斗者这三个字，那到底什么才是真正的奋斗者？主要包含以下几点： 1、有使命感，有持续艰苦奋斗的精神 2、共享价值观，团队合作，群体奋斗 3、讲奉献，多付出，提出挑战性绩效目标，终生奋斗 4、有意愿、有能力、有业绩、有贡献、持续价值创造者 5、不断接受挑战，勇于自我批判，实现自我超越者 谈到这五点，可能在大多数人的脑海中会涌现出老板经常给他们说过似曾相识的话；可能大多数人都会认为老板说的话大多是在给员工画饼，没有实际的意义。 试想，咱们换个角度思考，如果自己是老板，招来的员工都是这样的心态，那么企业如何做大做强呢？员工的薪水和职位又如何能够往上走呢？ 做了这么久的技术自媒体，杨工，您有什么感想要分享的吗？ 技术总监，送给刚毕业的程序员们一句话——做好小事，才能成就大事 上海出差之行–领略外滩美景、RT-Thread总部之旅、嵌友面基、返程记录 软技能：读袁总分享< >之人人皆可成为卓越的领导! 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

自己公司的产品，基于TencentOS tiny物联网操作系统；感谢TencentOS 官方公众号转发助力；以下为正文： 近年来，公共交通、快递运输、大型会议场馆会务等复合型服务业随着国民经济的快速发展，需求暴增，同时也暴露出来许多问题。如快递沦为一些不法分子犯罪的新渠道，快递网络正成为管制刀具、枪支弹药、易燃易爆品、危险化学品的运输流通渠道。公共交通和公共场所安检排查工作日益复杂，缺乏高效的违禁炸药、毒品等物质的检测手段，导致安检效率偏低。 随着反恐形势的不断升温，依靠科技手段提升安检排爆能力成为世界各国共同面对的重要课题。从技术原理上，安检排爆技术大致可以分为体检测和痕迹检测两种技术路径。体检测方法主要依靠如X射线，太赫兹，毫米波等技术通过成像等手段对人，物，车辆等进行安全检查；痕迹检测则是通过对待测目标挥发出的微痕量残留炸药等违禁品进行检测的技术。两类技术通常配合使用，以实现多个维度精准锁定违禁品。 基于这些背景，TencentOS Tiny 助力合作伙伴砺剑防卫打造了一套便携式的智能化高速安检设备。该设备融合了高速荧光检测技术、云端智能判图等多种融合违禁品检测技术。设备如下图： 危险物品的荧光传感薄膜探测原理 荧光淬灭痕迹炸药探测技术是痕迹检测领域的热点技术。相较于传统的IMS（离子迁移谱）技术，荧光淬灭拥有诸多优良性能。首先，荧光淬灭技术无需电离过程，所以操作便捷，体积小、重量轻、开机快、响应快、清洗快；其次，基于前端聚合物优良的“分子导线”效应，荧光淬灭传感器通常拥有更高的探测灵敏度；再者，相对于IMS模板库匹配的检测原理，荧光淬灭技术对混合炸药，土制炸药检测性能优良，实战性更强。基于这些优势，荧光痕量炸药探测器已经广泛运用在警卫安保，轨道交通，大型活动等重要安检排爆工作中。 手持式智能安检探测仪软硬件方案 手持式智能安检探测仪的应用 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

来源：https://segmentfault.com/a/1190000038292644 前言 我们经常会讨论这样的问题：什么时候数据存储在堆栈 (Stack) 中，什么时候数据存储在堆 (Heap) 中。我们知道，局部变量是存储在堆栈中的；debug 时，查看堆栈可以知道函数的调用顺序；函数调用时传递参数，事实上是把参数压入堆栈，听起来，堆栈象一个大杂烩。那么，堆栈 (Stack) 到底是如何工作的呢？本文将详解 C/C++ 堆栈的工作机制。阅读时请注意以下几点： 1）本文讨论的编译环境是 Visual C/C++，由于高级语言的堆栈工作机制大致相同，因此对其他编译环境或高级语言如 C# 也有意义。 2）本文讨论的堆栈，是指程序为每个线程分配的默认堆栈，用以支持程序的运行，而不是指程序员为了实现算法而自己定义的堆栈。 3)  本文讨论的平台为 intel x86。 4）本文的主要部分将尽量避免涉及到汇编的知识，在本文最后可选章节，给出前面章节的反编译代码和注释。 5）结构化异常处理也是通过堆栈来实现的(当你使用 try…catch 语句时，使用的就是  c++ 对 windows 结构化异常处理的扩展)，但是关于结构化异常处理的主题太复杂了，本文将不会涉及到。 从一些基本的知识和概念开始 1) 程序的堆栈是由处理器直接支持的。在 intel x86 的系统中，堆栈在内存中是从高地址向低地址扩展（这和自定义的堆栈从低地址向高地址扩展不同），如下图所示：  因此，栈顶地址是不断减小的，越后入栈的数据，所处的地址也就越低。 2) 在 32 位系统中，堆栈每个数据单元的大小为 4 字节。小于等于 4 字节的数据，比如字节、字、双字和布尔型，在堆栈中都是占 4 个字节的；大于 4 字节的数据在堆栈中占4字节整数倍的空间。 3) 和堆栈的操作相关的两个寄存器是 EBP 寄存器和 ESP 寄存器的，本文中，你只需要把 EBP 和 ESP 理解成 2 个指针就可以了。ESP 寄存器总是指向堆栈的栈顶，执行 PUSH 命令向堆栈压入数据时，ESP减4，然后把数据拷贝到ESP指向的地址；执行POP 命令时，首先把 ESP 指向的数据拷贝到内存地址/寄存器中，然后 ESP 加 4。EBP 寄存器是用于访问堆栈中的数据的，它指向堆栈中间的某个位置（具体位置后文会具体讲解），函数的参数地址比 EBP 的值高，而函数的局部变量地址比 EBP 的值低，因此参数或局部变量总是通过 EBP 加减一定的偏移地址来访问的，比如，要访问函数的第一个参数为 EBP+8。 4) 堆栈中到底存储了什么数据？包括了：函数的参数，函数的局部变量，寄存器的值（用以恢复寄存器），函数的返回地址以及用于结构化异常处理的数据（当函数中有 try…catch 语句时才有，本文不讨论）。这些数据是按照一定的顺序组织在一起的， 我们称之为一个堆栈帧（Stack Frame）。一个堆栈帧对应一次函数的调用。在函数开始时，对应的堆栈帧已经完整地建立了（所有的局部变量在函数帧建立时就已经分配好空间了，而不是随着函数的执行而不断创建和销毁的）；在函数退出时，整个函数帧将被销毁。 5) 在文中，我们把函数的调用者称为 caller（调用者），被调用的函数称为callee（被调用者）。之所以引入这个概念，是因为一个函数帧的建立和清理，有些工作是由 Caller 完成的，有些则是由 Callee 完成的。 开始讨论堆栈是如何工作的 我们来讨论堆栈的工作机制。堆栈是用来支持函数的调用和执行的，因此，我们下面将通过一组函数调用的例子来讲解，看下面的代码： int foo1(int m, int n){ int p=m*n;    return p;}int foo(int a, int b){    int c=a+1;        int d=b+1;        int e=foo1(c,d);        return e;}int main(){    int result=foo(3,4);    return 0;} 这段代码本身并没有实际的意义，我们只是用它来跟踪堆栈。下面的章节我们来跟踪堆栈的建立，堆栈的使用和堆栈的销毁。 堆栈的建立 我们从main函数执行的第一行代码，即 int result=foo(3,4); 开始跟踪。这时 main 以及之前的函数对应的堆栈帧已经存在在堆栈中了，如下图所示： 图1 参数入栈  当 foo 函数被调用，首先，caller（此时caller为main函数）把 foo 函数的两个参数：a=3,b=4 压入堆栈。参数入栈的顺序是由函数的调用约定 (Calling Convention) 决定的，我们将在后面一个专门的章节来讲解调用约定。一般来说，参数都是从右往左入栈的，因此，b=4 先压入堆栈，a=3…

本文介绍了如何解决STM32芯片Flash写保护导致无法下载程序，无法在线调试的问题；如果您遇到相同的问题，希望本文可以带来一些帮助； 1 FLASH的写保护 如果对Flash设置了写保护，那就无法对Flash进行编程和擦除。 在开发STM32的时候，如果出现这种情况，通常仿真器都支持对Flash进行解锁，像jlink，stlink等仿真器都支持这个功能。 2 错误提示 在使用MDK进行调试的时候，出现报错 ==Flash Timeout.Reset Target and try it again==，具体如下图所示； 折腾了一番之后，并没有解决问题，因为使用的仿真器是stlink，因此下载了stlink utility尝试解决问题； 3 stlink utility 3.1 基本功能 stlink utility是ST官方提供的免费软件，支持STM32 ST-LINK的程序包括带有命令行界面（CLI）的图形用户界面（GUI）。该工具还提供了较多的其他功能，具体如下； 可以对STM32 内部存储器 （Flash，RAM，OTP和其他存储器）， 外部存储器进行编程； 验证程序内容（校验和，在编程期间和之后进行校验，与文件进行比较等） 还能实现 STM32编程自动化； 另外还提供其他的功能； 3.2 解锁Flash 在stlink连接目标板的情况下，打开stlink utility，在菜单栏的Target下选择connect，因为这时候Flash已经被锁住了，所以同样地也看到相应的错误提示 Can not read memory Disable Read Out Protection and retry，具体如下图所示； OK，下面只需要接触写保护就行了，所以在菜单栏target里打开Option Bytes…选项，或者直接通过快捷键ctrl+B打开，请确保当前已经正确连接了stlink和目标板，否则会出现报错； 正确连接的情况下，打开Option Bytes…，发现在这里Read Out Protection选项是enable，这个表示无法通过swd读取STM32内部Flash的程序。 关键点：将Read Out Protection选项设置为disable，点击Apply，这时候Flash已经成功解锁了。但是同时发现，内部Flash已经被擦除了； 这可能STM32的保护机制有关，防止程序被拷机，然后进行反编译破解，这样也可以提高破解的门槛。具体显示如下图所示； 完成以上步骤之后，在菜单栏Target下选择Disconnect，或者通过快捷键ctrl+D断开和目标板的连接；重新进入MDK，就能正常对目标板进行调试，仿真，以及程序的烧写。 3.3 写保护 在菜单栏target里打开Option Bytes…选项，我们还看到下面有Flash sector protection选项；选择Select all之后，发现所有Page都已经写保护了，只要选择apply选项就可以对Flash进行写保护；具体如下所示； 4 总结 对于Flash写保护的问题可以结合STM32参考手册进行相应的学习，其内部Flash提供相应的保护机制，本文只是结合ST官方工具stlink utility解决一下常见的这个简单的问题。 笔者能力和水平有限，文中难免有错误和纰漏之处，请大佬们不吝赐教； – END – 推荐好文   点击蓝色字体即可跳转  全网最通俗易懂SPWM入门教程，快来白嫖  天哪！原来PWM这么简单  PID微分器与滤波器的爱恨情仇  简易PID算法的快速扫盲 增量式PID到底是什么？ 三面大疆惨败，因为不懂PID的积分抗饱和 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

1.说说Spring 里用到了哪些设计模式? 单例模式：Spring 中的 Bean 默认情况下都是单例的。无需多说。 工厂模式：工厂模式主要是通过 BeanFactory 和 ApplicationContext 来生产 Bean 对象。 代理模式：最常见的 AOP 的实现方式就是通过代理来实现，Spring主要是使用 JDK 动态代理和 CGLIB 代理。 模板方法模式：主要是一些对数据库操作的类用到，比如 JdbcTemplate、JpaTemplate，因为查询数据库的建立连接、执行查询、关闭连接几个过程，非常适用于模板方法。 2.谈谈你对IOC 和 AOP 的理解？他们的实现原理是什么？ IOC 叫做控制反转，指的是通过Spring来管理对象的创建、配置和生命周期，这样相当于把控制权交给了Spring，不需要人工来管理对象之间复杂的依赖关系，这样做的好处就是解耦。在Spring里面，主要提供了 BeanFactory 和 ApplicationContext 两种 IOC 容器，通过他们来实现对 Bean 的管理。 AOP 叫做面向切面编程，他是一个编程范式，目的就是提高代码的模块性。Srping AOP 基于动态代理的方式实现，如果是实现了接口的话就会使用 JDK 动态代理，反之则使用 CGLIB 代理，Spring中 AOP 的应用主要体现在 事务、日志、异常处理等方面，通过在代码的前后做一些增强处理，可以实现对业务逻辑的隔离，提高代码的模块化能力，同时也是解耦。Spring主要提供了 Aspect 切面、JoinPoint 连接点、PointCut 切入点、Advice 增强等实现方式。 3. JDK 动态代理和 CGLIB 代理有什么区别？ JDK 动态代理主要是针对类实现了某个接口，AOP 则会使用 JDK 动态代理。他基于反射的机制实现，生成一个实现同样接口的一个代理类，然后通过重写方法的方式，实现对代码的增强。 而如果某个类没有实现接口，AOP 则会使用 CGLIB 代理。他的底层原理是基于 asm 第三方框架，通过修改字节码生成成成一个子类，然后重写父类的方法，实现对代码的增强。 4. Spring AOP 和 AspectJ AOP 有什么区别？ Spring AOP 基于动态代理实现，属于运行时增强。 AspectJ 则属于编译时增强，主要有3种方式： 编译时织入：指的是增强的代码和源代码我们都有，直接使用 AspectJ 编译器编译就行了，编译之后生成一个新的类，他也会作为一个正常的 Java 类装载到JVM。 编译后织入：指的是代码已经被编译成 class 文件或者已经打成 jar 包，这时候要增强的话，就是编译后织入，比如你依赖了第三方的类库，又想对他增强的话，就可以通过这种方式。 加载时织入：指的是在 JVM 加载类的时候进行织入。 总结下来的话，就是 Spring AOP 只能在运行时织入，不需要单独编译，性能相比 AspectJ 编译织入的方式慢，而 AspectJ 只支持编译前后和类加载时织入，性能更好，功能更加强大。 5. FactoryBean 和 BeanFactory有什么区别？ BeanFactory 是 Bean 的工厂， ApplicationContext 的父类，IOC 容器的核心，负责生产和管理 Bean 对象。 FactoryBean 是 Bean，可以通过实现 FactoryBean 接口定制实例化 Bean…

分 享嘉宾： 付海涛 京 东 高级技术专家 编辑整理：赵明明 出品平台：DataFunTalk 导读：Flink是目前流式处理领域的热门引擎，具备高吞吐、低延迟的特点，在实时数仓、实时风控、实时推荐等多个场景有着广泛的应用。京东于2018年开始基于Flink+K8s深入打造高性能、稳定、可靠、易用的实时计算平台，支撑了京东内部多条业务线平稳度过618、双11多次大促。本次讲演将分享京东Flink计算平台在容器化实践过程中遇到的问题和方案，在性能、稳定性、易用性等方面对社区版Flink所做的深入的定制和优化，以及未来的展望和规划。主要内容包括： 实时计算演进 Flink容器化实践 Flink优化改进 未来规划 01 实时计算引进 1.发展历程 最初大数据的模式基本都是T+1，但是随着业务发展，对数据实时性的要求越来越高，比如对于一个数据，希望能够在分钟级甚至秒级得到计算结果。京东是在2014年开始基于Storm打造第一代流式计算平台，并在Storm的基础上，做了很多优化改进，比如基于cgroup实现对worker使用资源的隔离、网络传输压缩优化、引入任务粒度toplogy master分担zk压力等。到2016年，Storm已经成为京东内部流式处理的最主要的计算引擎，服务于各个业务线，可以达到比较高的实时性。 随着业务规模的不断扩大，Storm也暴露出许多问题，特别是对于吞吐量巨大、但是对于延迟不是那么敏感的业务场景显得力不从心。于是，京东在2017年引入了Spark Streaming流式计算引擎，用于满足此类场景业务需要。 随着业务的发展，不光是对于数据的延迟有很高要求，同时对于数据的吞吐处理能力也有很高的要求，所以迫切需要一个兼具低延迟和高吞吐能力的计算框架，于是在2018年我们引入了Flink。在Flink社区版的基础上，我们从性能、稳定性、易用性还有功能等方面，都做了一些深入的定制和优化。同时我们基于k8s实现了实时计算全面的容器化，因为容器化有很多的优点，它可以做到很好的资源隔离，同时它有一个很强的自愈能力，另外它很容易实现资源的弹性调度。同时我们基于Flink打造了全新的SQL平台，降低用户开发实时计算应用的门槛。 到2020年，基于Flink和k8s实时计算平台已经做的比较完善了。过去流式处理是我们关注的重点，今年我们也开始逐渐的支持批处理，朝着批流一体的方向演进。另外AI是目前比较火的一个方向，对于AI来说，它的实时化也是一个重要的研究方向。所以我们的实时计算平台将会朝着批流一体和AI的方向进行发展。 2.平台架构 上面是京东实时计算平台JRC的整体架构，整个架构以定制化改造后的Flink为核心，Flink运行在K8S上，状态存储在HDFS集群上，通过Zookeeper保证集群的高可用。支持流式源JDQ（京东基于Kafka深入定制实现的实时数据总线）和Hive，数据主要写入JimDB（京东内存数据库）、ES、Hbase和京东OLAP。计算平台支持SQL和普通JAR包两种方式的作业，具有配置、部署、调试、监控、和日志处理等功能。 3. 业务场景 京东Flink服务于京东内部非常多的业务线，有70多个一级部门在使用，主要应用场景包括实时数仓，实时大屏，实时推荐，实时报表，实时风控和实时监控，当然还有其他一些应用场景。对数据计算实时性有一定要求的场景，一般都会使用Flink进行开发。 4. 业务规模 京东Flink集群目前由5000多台物理机组成，它服务了京东内部70多个一级业务部门，目前线上的流计算任务大概有3000多个，数据的处理能力可以达到每分钟数十亿甚至更高。 02 Flink容器化实践 1.容器化历程 京东从2018年开始进行计算引擎的容器化改造，2019年初已经实现计算单元全部容器化，2020年进行了容器化方案升级，使用native k8s实现计算资源的弹性扩容。容器化改造的好处是提升了资源使用率，提高了研发效率，增强了业务稳定性，减少了运维部署成本。 2.容器化方案 旧的容器化方案是基于k8s Deployment部署的Standalone Session集群，它需要事先预估出集群所需资源，比如需要的JobManager和TaskManager的资源规格和个数。然后JRC平台通过K8S客户端向K8S Master提出请求，创建JobManager的Deployment和TaskManager的Deployment。其中使用ZK保证高可用，使用Hdfs实现状态存储，使用Prometheus实现监控指标的上传，结合Grafana实现指标的直观展示。集群使用ES存储日志，方便日志的查询。 3.容器化遇到的问题&对策 容器化过程中可能遇到很多问题： ① JM/TM故障自动恢复 应用部署在容器中，当应用出现异常时，如何发现应用或者异常的情况呢？比如可以使用存活探针，编写检测脚本定期读取应用的心跳信息。当检测到Pod处于不健康状态时，可以采用k8s的重启机制来重启不健康的容器。 ② 减少Pod异常对业务影响 在k8s中由于硬件异常、资源过载、Pod不健康等问题会导致Pod被驱逐或自动重启，Pod重启时势必会影响到该Pod上分布计算任务的正常运行。这个时候可以考虑采用适当的重启策略、改造内核等方案来减少对任务影响。比如京东实现了JM Failover优化，当Pod异常引起JM Failover时采用的是任务不恢复、重建任务状态恢复的方式，可以一定程度上减少Pod重启对业务带来的影响。 ③ 性能问题 在容器环境下，JVM对cpu和内存的感知会有一定的问题，在Java8版本中，一些参数就要进行显式的设置。对于机器性能差异或热点等问题导致部分Pod计算慢的问题，可以考虑进行针对性优化（比如实现基于负载的数据分发）或处理（比如检测到计算慢的Pod将其驱逐到负载较低的机器）。此外，对于使用容器网络的情况下，可能会带来一定的网络性能损耗，此时可以根据情况选择使用主机网络避免网络虚拟化带来的开销，或者选择更高性能的网络插件。 ④ 重要业务稳定性 如何保证业务的稳定性是一个需要重点考虑的问题。除了保证系统各个环节的高可用外，还可以根据业务情况考虑使用其它合理的方案，例如业务分级管理，独立资源池，多机房互备等。 4.容器化方案升级（Native k8s） 原有容器化方案存在一定的问题： 资源需要提前分配 无法实现资源弹性伸缩 极端场景下Pod不能正常拉起，影响任务恢复 重要业务稳定性 容器化升级的解决方案是采用Native K8s的方式。由JRC平台先向K8S Master发出请求，创建JobManager的Deployment；然后在用户通过Rest服务提交任务后，由JobMaster通过JDResourceManager 向JRC平台发出请求，然后JRC平台向 K8s Master 动态申请资源去创建运行TaskManager 的Pod。 此处，通过引入JRC平台与K8s交互，屏蔽了不同容器平台的差异，解耦了镜像与平台集群配置&逻辑变化。另外，为了兼容原有Slot分配策略，在提交任务时会预估出任务所需资源并一次性申请，之后采用等待一定时间后进行slot分配的方式达到兼容目的。 03 Flink优化改进 主要做了以下四个方面的优化： 性能 稳定性 易用性 功能扩展 下边分几个重要的点进行讲解： 1.预览拓扑 预览拓扑主要是为了解决业务的一些痛点：比如任务调优繁琐、SQL任务无法指定并行度、任务需要的额Slot数不清楚、并行度调整后网络buffer不足等。在Flink任务调试阶段，对任务并行度、Slot分组、Chaining策略的调整是个反复的过程，如果把参数写到命令行就太繁琐了。而基于预览拓扑就可以很方便地对这些参数进行配置。 预览拓扑基本的实现方案如上图：用户提交JAR包后可根据JAR包生成对应的拓扑图，之后用户根据拓扑图可以进行在线调整，最后自动将修改后的配置和原来的JAR包一起进行任务提交。 预览拓扑机制使得不修改程序多次提交任务调优成为可能，但是如何保证前后两次提交生成算子稳定的对应关系呢？解决方案的关键是保证算子有稳定的唯一身份标识，具体算法是：如果算子指定了uidHash就用uidHash，如果算子指定了uid就使用uid，否则就从source开始广度优先遍历，利用算子在graph中的位置生成一个稳定hash值。 2.背压量化 第二个重要的优化是背压量化。 在Flink开发的时候，主要有两种方式： ①通过Flink UI背压面板观察是否背压。使用这种方式在某些场景比较方便，但是它存在几个问题： 在有些场景下采集不到背压 对于历史背压情况无法跟踪 背压影响不直观 大并行度时背压采集压力 ②通过任务背压相关指标进行观察和分析，通过将指标定期采集并存储起来，可以进行实时或历史的背压分析。但是它也有一些不足的地方： 不同Flink版本中指标含义有一定差异 分析背压有一定门槛，需要对于指标含义有深入理解，联合进行分析 背压未量化，对业务影响程度不够直观 京东的解决方案是采集背压发生的位置、时间和次数指标，并对这些指标进行上报存储。同时对量化的背压指标结合运行时拓扑，可以精确反映发生背压现场的情况。 3.HDFS优化 随着业务数量的增多，HDFS集群的压力就会变得很大。这会直接导致RPC响应时间变慢，造成请求堆积，同时大量小文件也会对NN内存造成很大压力。对此京东尝试的解决方案有4方面：限制checkpoint最小间隔，时间最小设置在1min左右可以满足大部分业务需求；进行小文件合并；降低cp创建和删除时的hdfs rpc请求；HDFS集群多ns分散均衡压力。 4.网络分发优化 在实践过程中我们发现，即使业务使用了rebalance并且对任务进行了打散分布，但是由于机器处理能力和负载的差异，会导致任务各个并行度不同程序的背压表现，严重影响了任务的性能。为此，我们开发了基于负载的动态rebalance，在数据进行分发时优先选择下游负载最小的channel进行分发。 经测试，在特定场景下性能能够提升近一倍。 5.ZK防抖 目前一般都是使用ZK集群实现Flink集群的高可用，但是当网络抖动、机器繁忙、ZK集群暂时无响应或运维机器的时候，都可能会导致任务重启。 任务重启的原因是由于在这些场景发生时，Curator会将状态设置为suspended，并且Curator认为suspended为Error状态，从而会释放leader，Flink发现notleader后会revokeLeadership，从而造成任务重启。 一个可行的解决办法是升级Curator的版本，同时将connectionStateErrorPolicy设置为SessionConnetionStateErrorPolicy。 6.日志分离 目前我们一个集群是支持跑多个任务的，这时日志会出现的问题是：任务的日志和集群Framework日志混在一起，同时集群的多个任务日志也是混在一起的，不太方便用户查看日志，快速定位问题。 为了解决这个问题，首先要弄清楚目前Flink加载日志框架的基本机制：为了避免跟业务Job中可能包含的日志框架的依赖、配置文件产生冲突，Flink日志相关类的加载都代理给TaskManager框架的类加载器，也就是Parent Classloader，而框架加载的这些类都是从Flink安装包的lib目录下加载的。对于日志配置文件，Flink通过 JVM 启动参数来指定配置日志配置文件路径。 日志分离的解决方案是：将日志相关jar包加入到各个task自己classloader（user classloader）的类路径中；同时确保使用user classloader加载日志类和加载自己的日志配置； 另外对于使用了Flink框架的类（比如PrintSinkFunction），日志不能做到很好的分离，可以考虑使用logback MDC机制。 04 未来规划…

宜普电源转换公司(EPC)宣布推出EPC9151，这是一款300 W、双向、超小尺寸的1/16砖型DC/DC降压转换器模块，其尺寸仅为33 mm x 22.9 mm (1.3”x 0.9”)。EPC9151采用Microchip公司的数字信号控制器(dsPIC33CK)和EPC公司的 ePower™ 功率级集成电路(EPC2152)，于300 W、48 V/12 V的转换器中，可以实现95%以上的效率，而且可以在这个可扩展的两相设计中增加相数，使得功率可以更高。 砖型DC/DC转换器广泛用于数据中心、电信和车载应用，可将标称48 V总线转换为标称12 V配电总线(或从标称12 V总线转换)。氮化镓集成电路技术的迅猛发展推动了半桥器件和栅极驱动器的集成，EPC9151模块就是采用了单芯片解决方案(EPC2152)，从而针对各种目标应用，简化布局、减小面积并降低成本。 EPC首席执行官Alex Lidow表示：“ 氮化镓场效应晶体管(eGaN FET)和集成电路具备快速开关、小尺寸和低成本等优势，以满足前沿计算应用对功率密度的严格要求。EPC9151是很好的范例，它展示如何利用集成功率级EPC2152，满足计算应用中48 V转换所要求的提高功率密度并降低系统成本。”

· Nuheara IQbuds2 MAX产品凭借出色的音质和个性化的听觉增强功能而广受好评 · 艾迈斯半导体主动降噪技术为Nuheara耳塞用户实现“聆听其想听的声音”的体验 中国，2020年12月21日——全球领先的高性能传感器解决方案供应商艾迈斯半导体(ams AG)今日宣布，其主动降噪(ANC)芯片技术为Nuheara“全球先进的耳塞”——新款IQbuds2 MAX产品提供个性化的降噪。 Nuheara耳塞的特别魅力在于，它集出色的播放音质与个性化的听觉增强特性于一体。这款零售价为379欧元的耳机为一些有轻度听力障碍但暂时不想使用助听器，同时又希望获得出色聆听体验的消费者提供一个新的选择。 艾迈斯半导体音频传感器市场经理Christian Feierl表示：“Nuheara为新型智能听觉设备开创了先河。对部分消费者而言，传统听觉解决方案难以令人满意。而该设备的出现将能改善这些人的听觉体验。艾迈斯半导体的宽带主动降噪技术对于此类产品而言至关重要，让听觉耳塞能够有效阻隔来自周围环境的声音干扰。” 耳塞音频性能好评如潮 IQbuds2 MAX在全球赢得了广泛好评，包括2020年《时代》杂志100项最佳发明，以及2020年CES三项创新奖。Nuheara的EAR ID个性化系统给很多使用者留下了深刻印象。用户既可以达到双耳的听觉阈值，也可以根据自己的听觉曲线校准耳塞。 声音再现和听觉增强这两项是打动使用者的杰出特性，有赖于艾迈斯半导体业界先进的主动降噪芯片技术提供的出色降噪——在宽频范围内其典型值超过30dB。艾迈斯半导体的主动降噪技术可实现近乎静默的声学背景，使得Nuheara的IQbuds2 MAX可投射用户所选类型的声音，帮助消费者“聆听您想听的声音”。 艾迈斯半导体近期开展的“舒适、智能、高性能耳塞的市场调查”发现，除了性能、舒适性和佩戴牢固之外，数字主动降噪也是耳塞制造商的重要差异化因素。 Nuheara联合创始人兼首席营销官David Cannington表示：“艾迈斯半导体的主动降噪技术是IQbuds2 MAX提供听觉增强特性的关键。这不仅是因为艾迈斯半导体主动降噪芯片带来了优异的降噪，艾迈斯半导体音频专家在调校和设计方面也为我们设计工程团队提供了大力支持。” 艾迈斯半导体在音频领域一直有着持续突破保持创新的优良传统历史，数字听觉增强等技术的推出符合艾迈斯半导体一贯的传统作风。十多年来，降噪耳机制造商一直使用艾迈斯半导体的模拟ANC芯片，借以在降噪深度、带宽以及超低功耗保持出色水平。艾迈斯半导体还致力于为耳机制造商提供专业知识与经验，帮助他们优化产品设计的声学、机械结构和电气性能，从而巩固自己的市场地位。 2016年艾迈斯半导体收购Incus Laboratories，从而拥有全新的数字音频技术，进而同时拥有数字以及模拟两大技术杀手锏。作为这次并购行动结出的硕果，听觉增强引擎平台为全入耳式耳机和半入耳式耳机带来了多项功能，如“自适应泄漏补偿(ALC)”、“自动预设选择(APS)”和“聆听您想听的声音”等等。 接下来的创新技术将包含密封式自适应泄漏补偿功能，它能弥补耳塞佩戴的不完美，并将主动降噪性能提高到50dB+。

关注、星标公众号 ， 直达精彩内容 ID：技术让梦想更伟大 整理：李肖遥 单片机主要作用是控制外围的器件，并实现一定的通信和数据处理。 但在某些特定场合，不可避免地要用到数学运算，尽管单片机并不擅长实现算法和进行复杂的运算。 下面主要是介绍如何用单片机实现数字滤波。 在单片机进行数据采集时，会遇到数据的随机误差，随机误差是由随机干扰引起的，其特点是在相同条件下测量同一量时，其大小和符号会现无规则的变化而无法预测，但多次测量的结果符合统计规律。 为克服随机干扰引起的误差，硬件上可采用滤波技术，软件上可采用软件算法实现数字滤波。滤波算法往往是系统测控算法的一个重要组成部分，实时性很强。 采用数字滤波算法克服随机干扰的误差具有以下优点： 数字滤波无需其他的硬件成本，只用一个计算过程，可靠性高，不存在阻抗匹配问题。尤其是数字滤波可以对频率很低的信号进行滤波，这是模拟滤波器做不到的。 数字滤波使用软件算法实现，多输入通道可共用一个滤波程序，降低系统开支。 只要适当改变滤波器的滤波程序或运算，就能方便地改变其滤波特性，这对于滤除低频干扰和随机信号会有较大的效果。 在单片机系统中常用的滤波算法有限幅滤波法、中值滤波法、算术平均滤波法、加权平均滤波法、滑动平均滤波等。 限幅滤波算法 该运算的过程中将两次相邻的采样相减，求出其增量，然后将增量的绝对值，与两次采样允许的最大差值A进行比较。 A的大小由被测对象的具体情况而定，如果小于或等于允许的最大差值，则本次采样有效;否则取上次采样值作为本次数据的样本。 算法的程序代码如下： 1#define A  //允许的最大差值 2 3char data;  //上一次的数据 4 5char filter() 6 7{ 8 9     char  datanew;  //新数据变量 10 11    datanew=get_data();  //获得新数据变量 12 13     if((datanew- data)>A||( data-datanew>A)) 14 15         return  data; 16 17     else 18 19         return  datanew; 20 21} 说明： 限幅滤波法主要用于处理变化较为缓慢的数据，如温度、物体的位置等。使用时，关键要选取合适的门限制A。通常这可由经验数据获得，必要时可通过实验得到。 中值滤波算法 该运算的过程是对某一参数连续采样N次(N一般为奇数)，然后把N次采样的值按从小到大排列，再取中间值作为本次采样值，整个过程实际上是一个序列排序的过程。 算法的程序代码如下： 1 #define N 11 //定义获得的数据个数 2 3 char filter() 4 5 { 6 7     char value_buff[N];  //定义存储数据的数组 8 9     char  count,i,j,temp; 1011     for (count= 0 ;count 1213     { 1415         value_buf[count]=get_data(); 1617         delay();  //如果采集数据比较慢，那么就需要延时或中断 1819     } 2021     for (j= 0 ;j 2223     { 2425         if (value_buff[i]>value_buff[i+ 1 ]) 2627         { 2829             temp=value_buff[i]; 3031             value_buff[i]=value_buff[i+ 1 ]; 3233             value_buff[i+ 1 ]=temp; 3435         } 3637    …

2020年12月19日，2020中国. NET开发者大会于苏州盛大开幕。本次大会以“开源、共享、创新”为主题，以线下城市苏州为中心，覆盖北京、上海、深圳、广州、长沙、成都、厦门、胶东等地区，是中国 .NET 开发者的大聚会，线上+线下参会人数达数十万人，覆盖城市达10+个。峰会共包含5大会场，近50场热点技术专题，数万名开发者将就各类“ .NET 开发和产品设计”相关的前沿技术话题展开深度交流。 此次开发者大会上，龙芯.NET项目及JVM负责人敖琪博士发表了《龙芯.NET到来》主题演讲，并正式发布龙芯.NET。这意味着国产龙芯已支持.NET，具备更为灵活的部署能力，也将进一步完善龙芯软件生态开发体系。会上，微软全球开发平台事业部资深副总裁Julia Liuson女士特别提到：“中国的.NET社区也积极为.NET开源项目做出了很多贡献，其中特别提一下，对龙芯平台的移植是一个非常大的工程，谢谢龙芯团队。” 此次发布的龙芯.NET 3基于.NET Core 3.1，支持该版本具备的所有主要功能，包括GC、AOT等。CoreCLR、CoreFX、ASP.NET Core等库的测试通过情况与x64/arm64相当。同时支持龙芯CPU家族，包括龙芯3A4000/3A3000/3A2000单路多路、龙芯2K1000等。支持多款操作系统，包括Loongnix、Debian、UOS、麒麟等。后续，龙芯将对龙芯. NET进行长期维护，并与社区同步。 从去年开始，龙芯将.NET作为一个重点项目持续跟进。2019年5月开始调研需求及版本。2019年8月构建成功，10月输出第一个Hello World，并完成虚拟机初始化、部分JIT和打印功能。2020年5月.NET Web应用启动，6月18日开源了龙芯版本的CoreCLR，7月发布早期试用版，12月推出发布候选版本。 未来龙芯将持续不断完善.NET产品质量，为用户提供更好的服务和使用体验。龙芯也将积极参与.NET社区建设，将龙芯的工作回馈给社区，并争取合入上游。同时号召.NET领域开发人员及国内爱好者一起参与.NET虚拟机的学习和研究，龙芯愿意帮助更多国内开发者了解底层技术，从CoreCLR等底层平台中获取更多土壤，也将有利于更好掌握.NET优秀技术。 感兴趣的开发者可通过龙芯提供的开源仓库自己动手编译，了解该版本的实际情况。