【记录】线程池卡死现象 在funA中异步调用funB,由于大量的funA耗尽线程池中的线程,funB一直在等待funB中的任务完成,将funB中的任务放入阻塞队列,但是已经无线程可以使用,无人处理,于是造成了funA等待funB完成,fanB等待其中任务完成,最终导致卡死。在使用线程池时,错误的将completableFuture当成一种银弹,导致线程池卡死。
刷算法-- leetcode 96. 不同的二叉搜索树 思路观察树的组成,可以发现n=3时的二叉搜索树可以由,头节点分别为1、2、3时的所有结果组成!定义dp[i]为由i个节点组成的二叉搜索树的个数。确定递推公式,dp[i] = 由1为头节点组成的二叉搜索树个数+由2为头组成的个数+…+由i为头节点组成的个数。所以,进一步分析:由1为头节点组成的二叉搜索树个数=左子树个数为0时搜索树个数*右子树节点数为2时的搜索树个数.由2为头节点时组成的搜索树个数=左子树包含1个节点是的搜索树个数*右子树节点数为2时的搜索树个数节点数量为2时的搜索树个数=
洛谷----皮特的烟(递归) package 刷题.入门;import java.util.Scanner;public class Peter的烟 { public static void main(String[] args) { Scanner scanner=new Scanner(System.in); int n = scanner.nextInt(); int k = scanner.nextInt(); int res=get(n, k); System.out.println(res+n
mysql: /usr/local/MATLAB/MATLAB_Runtime/v901/sys/os/glnxa64/libstdc++.so.6: version `CXXABI_1.3.9‘ n 项目场景:运行在centos中,执行mysql指令出错mysql: /usr/local/MATLAB/MATLAB_Runtime/v901/sys/os/glnxa64/libstdc++.so.6: version `CXXABI_1.3.9’ not found (required by mysql) centos问题描述:执行终端mysql命令出错原因分析:matlab中的libstdc++与系统自带的冲突。解决方案:删除其中一个就可以1.查看系统所有关于 'libstdc
java.lang.UnsatisfiedLinkError: org.opencv.core.Mat.n_Mat(IIILjava/nio/ByteBuffer;)J [duplicate] java.lang.UnsatisfiedLinkError: org.opencv.core.Mat.n_Mat(IIILjava/nio/ByteBuffer;)J [duplicate]如果你只用maven导入了的话 可以在程序前面加上 以下代码:Loader.load(opencv_java.class)
matlab代码打成jar包 并在idea中使用 首先要保证电脑安装了jdk1.6(版本不能太高 我以2016的matlab为例)和matlab在matlab 命令行输入以下:然后在cmd 窗口中输入这里两个的版本要是一致的。在matlab中输入选择Library compiler这里可以搜索其他的博主文章来操作(我的不详细);点击绿色对勾 打包然后把生成的jar包放到idea,而且还需要安装MCR然后 还要在项目中再加一个jar包路径在matlab的MCR的toolbox的javabuilder中两个jar包如图所示 一
springboot自定义messageConverter 如果想自定义传输数据的类型 需要设置自己的messageConverterpublic class YanMessageConverter implements HttpMessageConverter { @Override public boolean canRead(Class clazz, MediaType mediaType) { return false; } @Override public boolean canWrite(Cl
一句话让spring-boot帮我开启浏览器参数内容协商策略 一句话:背后的原理:当我们开启参数协商以后在RequestResponseBodyMethodProcessor里 有个方法有个writeWithMessageConverter 这里包含消息的读和写操作 进入查看发现:里面有个获取request的可以接受的类型 继续进入调用了一个内容协商管理器的方法。进入方法此方法遍历所有的strategy 我们查看此时的策略发现此时存在两个策略一个是参数内容协商 另外是请求头内容协商。oh 原来当我们写下那句 spring.mvc.conte
HttpMessageConverter原理 1.判断当前响应是否有了确定的媒体类型。2.获取客户端支持的接受类型。(header accept 字段 )这里用postman故意设置为xml然后找到一个合适的converter进行write
spring-boot源码分析--响应json 返回值处理 1,spring-boot 引入web包后带有json的stater。只需在类方法上面responseBody就可以。2,有返回值解析器returnValueHandlers进行处理。3,执行完这个方法后,得到返回值,进行一些返回值安全判断后。4,使用返回值处理器进行处理。下面分析这个方法怎么处理:1.首先调用了这个方法:stepover --》stepinto2.来到真正的处理方法中:首先,选择一个对应的handler返回值处理器会判断返回值处理器是否支持处理该类型返回值,支
2.7.11,java.lang.NoSuchMethodError: org.apache.curator.framework.recipes.cache.NodeCache.getListenab 在学习zookeeper与dubbo时出现该问题建议降低 curator包的版本 改为4.x以后解决参考文章