上下文

遇到过的问题： 情景1： 在使用SessionFactory的getCurrentSession方法时遇到如下错误，经过检查，原因如下： 是因为在hibernate.cfg.xml文件中忘记进行了如下设置： hibernate.current_session_context_class如果是在web容器中运行hibernate，则在hibernate.cfg.xml中加入这句话： <property name="hibernate.current_session_context_class">jta</property> 如果是在一个单独的需要进行JDBC连接的java application中运行hibernate，则这样设置： <property name="hibernate.current_session_context_class">thread</property> 情景2： 在ssh2中的sessionFactory配置文件中 应将hibernate.current_session_context_class设为org.springframework.orm.hibernate3.SpringSessionContext（默认为此值） 并应用spring管理事务。如果为<prop key="hibernate.current_session_context_class

我们开发任何一个Spring Boot项目，都会用到如下的启动类 @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } 从上面代码可以看出，Annotation定义（ @SpringBootApplication ）和类定义（ SpringApplication.run ）最为耀眼，所以要揭开SpringBoot的神秘面纱，我们要从这两位开始就可以了。 一、SpringBootApplication背后的秘密 @SpringBootApplication注解是Spring Boot的核心注解，它其实是一个组合注解： @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes =

我们在Python中对于with的语句应该是不陌生的，特别是在文件的输入输出操作中，那在具体的使用过程中，是有什么引伸的含义呢？与之密切相关的上下文管理器(context manager)又是什么呢？ 什么是上下文管理器 在任何一种编程语言里，文件的输入输出、数据库的建立连接和断开等操作，都是很常见的资源管理操作。但是资源是有限的，在写程序的时候，我们必须保证这些资源在使用后得到释放，不然就容易造成资源泄漏，轻者系统处理缓慢，重则系统崩溃。 我们看一个例子： for i in range(100000000): f = open('test.txt','w') f.write('hello') 我们在循环里打开了100000000个文件，但是在使用完毕后没有进行关闭操作，一运行代码，就报错了。 这就是一个典型的资源泄漏的案例，因为程序中同时打开了太多的文件，占用了太多的资源，造成崩溃。 为了解决这个问题，不同的编程语言都引入了不同的机制，在Python中，对应的解决方法就是上下文管理器(context manager)。上下文管理器能够自动分配资源并释放资源，其中最典型的应用就是with语句，所以上面的代码应该用这种方式来写 for x in range(100000000): with open('test.txt','w') as f: f.write('hello world

3.2什么样的服务是好服务 在MusicCorp的团队为了把八轨带（eight track tape)递送到所有人手中而开始辛苦工作、 创建一个又一个的服务之前，让我们先缓缓，讨论一些很重要的基本原则。什么是好的服 务？如果你曾经尝试过SOA并且失败了，大概就知道我下一步要说什么了。不过万一你 没那么幸运（不幸），我希望你专注在两个重要的概念上：松耦合和高内聚。在本书的剩 余部分，我们会讨论更多的实践和细节，因为如果这两点做不到，那么微服务也就没什么 价值了。 这两个概念在不同的上下文中被大量使用，尤其是在面向对象编程中，所以，我们先讨论 一下这两个概念在微服务中是什么含义。 3.2.1松耦合 如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一个服务。使用微服务 最重要的一点是，能够独立修改及部署单个服务而不需要修改系统的其他部分，这真的非 常重要。 什么会导致紧耦合呢？ 一个典型的错误是，使用紧辋含的方式做服务之间的集成，从而使 得一个服务的修改会致使其消费者的修改。第4章会进一步讨论如何避免这种问题。 一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。这也意味着，应该限 制两个服务之间不同调用形式的数量，因为除了潜在的性能问题之外，过度的通信可能会 导致紧耦合。 3.2.2高内聚 我们希望把相关的行为聚集在一起，把不相关的行为放在别处。为什么呢？因为如果你要

壹 ❀ 引 在本文之前我已经花了两个篇幅专门介绍了JavaScript中的闭包与this，正好今早地铁上看到了两道面试题，试着做了下发现挺有意思，所以想单独写一篇文章来记录解析过程。若你对于闭包与this有所了解，不妨先看自己的理解是否正确，若你对于这部分知识欠缺，还是建议先阅读我前面的两篇文章，链接在下： 一篇文章看懂JS闭包，都要2020年了，你怎么能还不懂闭包？ js 五种绑定彻底弄懂this，默认绑定、隐式绑定、显式绑定、new绑定、箭头函数绑定详解 那么本文开始。 贰 ❀ 题一 /*非严格模式*/ var name = 'window' var obj1 = { name: '听风是风', fn1: function () { console.log(this.name) }, fn2: () => console.log(this.name), fn3: function () { return function () { console.log(this.name) } }, fn4: function () { return () => console.log(this.name) } } var obj2 = { name: '行星飞行' }; obj1.fn1();//? obj1.fn1.call(obj2);//? obj1.fn2();//? obj1

自定义系统类加载器 ClassLoader.getSystemClassLoader()方法详解 方法说明 返回用于委托的系统类加载器，它是新建ClassLoader实例的默认的委托双亲，通常也是启动应用的类加载器。 这个方法在运行启动期间很早的时候就被调用，在调用时首先会创建系统加载器，而且会将其设置为调用该线程的上下文类加载器。 默认的系统类加载器是与这个类的实现相关的一个实例。 如果系统属性 java.system.class.loader 被定义了，这个属性的值就将做为返回的类加载器的名字。这个类是使用默认的系统类加载器所加载的，且必须要定义一个默认的参数为 ClassLoader 的构造方法，所生成的类加载器就被定义为新的系统类加载器。 如果安全管理器存在，并且调用者的类加载器是不是 null 和调用者的类加载器是不一样的，或者系统类加载器的祖先，则此方法调用安全管理器的 checkPermission 方法与 RuntimePermission("getClassLoader") 权限验证访问到系统类加载器。 如果没有， SecurityException 将被抛出。 源码解析 // 系统类加载器 // @GuardedBy("ClassLoader.class") private static ClassLoader scl; // 设置系统类加载器后

引言 上下文切换（有时也称做进程切换或任务切换）是指 CPU 从一个进程或线程切换到另一个进程或线程。上下文切换会影响多线程执行速度。死锁是指多个进程或线程循环等待它方占有的资源而无限期地僵持下去的局面。 1、上下文切换 上下文定义 cpu发生进程或者线程切换时，所依赖的数据集合，比如一个函数有外部变量，函数运行时，必须获取外部变量，这些变量值的集合就是上下文。 引发问题 对于CPU密集型任务，多线程处理会发生上下文切换，会影响到执行速度，如果时IO密集型，多线程技术优点尽显。 如何减少上下文切换 无锁并发编程，锁的获取与释放会发生上下文切换，多线程时会影响效率。无锁并发编程就是将数据分块，每个线程处理各自模块。比如LongAdder中部分代码。 CAS算法，并发编程时通过CAS算法更新数据，而不必加锁。如Java的atomic包下的工具类。 使用最少线程，减少不必要的线程创建，自定义线程池。 使用协程，在单线程中维护多任务调度，处理任务间切换，Golang对于协程的使用很强大。 2、死锁 死锁定义 死锁是进程死锁的简称，是由Dijkstra于1965年研究银行家算法时首先提出来的。 系统发生死锁现象不仅浪费大量的系统资源，甚至导致整个系统崩溃，带来灾难性后果。 产生死锁原因 系统资源不足 进程推进顺序不当 资源分配不合理 死锁产生的必要条件 互斥条件

背景： 目前，在实时跟踪领域存在着越来越多的先进方法，同时也极大地促进了该领域的发展。主要有两种不同的基于深度学习的跟踪方法：1、由在线跟踪器组成，这些跟踪器依赖网络连续的微调来学习目标的变化外观，精度虽高，但无法满足实时要求；2、基于相关滤波器的跟踪器组成，利用原始深度卷积特征，如Imagenet中包含的一般对象，存在高维度的问题，另外，相关滤波器计算时间随着特征维度的增加而增加，也不满足实时要求。 在2018年的CVPR会议上，出现了这样一篇文章：《Context-aware Deep Feature Compression for High-speed Visual Tracking》，引起了不小的反响。主要提出了一种新的基于上下文感知的相关滤波器的跟踪框架，以实现一个实时跟踪器。在计算速度和精度方面都有着不错的成绩。速度提升主要来源于深度特征压缩，利用多个expert auto-encoder的上下文感知方案；上下文是指根据不同层特征图对跟踪目标的粗略分类。在预训练阶段，每个类别训练一个expert auto-encoder。在跟踪阶段，指定一个最佳expert auto-encoder。为了实现高效跟踪性能，引入外部去噪处理和新的正交性损失项orthogonality loss，用于expert auto-encoder的预训练和微调。在保持当前最佳性能的同时

在上篇文章中，我们讲了词法作用域、作用域链以及闭包，接下来我们分析一下这段代码： var bar = { myName:"time.geekbang.com", printName: function () { console.log(myName) } } function foo() { let myName = "极客时间" return bar.printName } let myName = "极客邦" let _printName = foo() _printName() bar.printName() 在 printName 函数里面使用的变量 myName 是属于全局作用域下面的，所以 最终打印出来的值都是“极客邦” 。这是因为 JavaScript 语言的 作用域链是由词法作用域决定的 ，而 词法作用域是由代码结构来确定 的。 不过按照常理来说，调用bar.printName方法时，该方法内部的变量 myName 应该使用 bar 对象中的，因为它们是一个整体，大多数面向对象语言都是这样设计的，比如我用 C++ 改写了上面那段代码，如下所示： #include <iostream> using namespace std; class Bar{ public: char* myName; Bar(){ myName = "time.geekbang.com"; }

目录 一、前言 二、spring mvc 核心类与接口 三、spring mvc 核心流程图 四、spring mvc DispatcherServlet说明 五、spring mvc 父子上下文的说明 六、springMVC-mvc.xml 配置文件片段讲解 七、spring mvc 如何访问到静态的文件，如jpg,js,css 八、spring mvc 请求如何映射到具体的Action中的方法 九、 spring mvc 中的拦截器： 十、 spring mvc 如何使用拦截器 十一、 spring mvc 如何实现全局的异常处理 十二、 spring mvc 如何把全局异常记录到日志中 十三、 如何给spring3 MVC中的Action做JUnit单元测试 十四、 spring mvc 转发与重定向 （带参数重定向） 十五、 spring mvc 处理ajax请求 十六、 spring mvc 关于写几个配置文件的说明 十七、 spring mvc 如何取得Spring管理的bean 十八、 spring mvc 多视图控制器 十九、 <mvc:annotation-driven /> 到底做了什么工作 二十、 本文中springMVC.xml配置文件是核心，这里给一个下载地址 说明：本作者是文章的原创作者，转载请注明出处：本文地址： http://elf8848