Optional开发中记录
首先，Optional是一个容器，用于放置可能为空的值，它可以合理而优雅的处理null。 不合适的使用方式 直接使用 isPresent() 进行 if 检查 -- isPresent()一般用于流处理的结尾，用于判断是否符合条件。 在方法参数中使用 Optional public void getUser(long uid, Optional<> userType); -- X 直接使用 Optional.get -- 和不做任何空判断一样，十分危险 使用在 POJO 中 -- 给序列化带来麻烦 记录一些API12345678910111213141516171819202122232425262728291. empty()返回一个Optional容器对象，而不是 null。建议常用⭐⭐⭐⭐2. of(T value)创建一个Optional对象，如果 value 是 null，则抛出 NPE。不建议用⭐⭐3. ofNullable(T value)同上，创建一个Optional对象，但 value 为空时返回Optional.empty()...
Reactive编程学习记录(长期)-知识及编程技巧
问题记录 最后的结果Flux、Mono一定要作为方法返回值，因为响应式编程的异常信息保存在这些结果中（而不是在方法调用时抛出），所以这些结果必须作为方法返回值，否则Spring无法知道方法是否报错 常用api记录 如果要操作数据,并返回一个Mono的时候,使用flatMap 一般如果不操作数据,仅数据转换,使用map 订阅者是由Spring框架去完成,我们(开发)写发布者代码 zipWith方法可以组合两个Mono/Flux，并返回新的Mono/Flux类型 take(x)适合取flux中前x个,而当flux就一个元素的适合,可以使用next()将flux转为mono flatMapMany适合将Mono<数组/集合>转换为Flux 当希望合并多个流操作的时候,可以使用Mono.zip/Flux.zip Mono.zip(memberLevelMono, giftCardMono, couponMono).map... zipWith方法会同时请求待合并的两个Mono数据，而zipWhen方法则会阻塞...
Reactive编程学习记录总结
webmvc和webflux的一些区别组件 执行过程webmvc webflux 写法(返回一个视图)webmvc webflux(路由式写法),webflux也支持了mvc的注解使得一般项目可以无压力替换为webflux框架 思想webmvc(命令式编程)1假如有一个式子a=b+c，这就意味着a的值是由b和c计算出来的。如果b或者c后续有变化，不会影响到a的值 webflux(响应式编程)123式子a:=b+c，这就意味着a的值是由b和c计算出来的。但如果b或者c的值后续有变化，会影响到a的值--变化传递 例子(3y) 1234567private String createStr() { try { TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { } return "some string";} webmvc123456private String get1() &...
记录Reactive编程模式下如何方便的debug
通过打开全局 Operator 堆栈追踪 未开启之前 开启之后 这种方法同等与在方法内部输出以下代码1234//打开Hooks.onOperatorDebug();//关闭Hooks.resetOnOperatorDebug();
记录RouterFunction方式如何实现全局异常拦截
在使用mvc编程方式下,全局异常拦截可使用如下方式123456789101112131415/** * @author 小五 */@Slf4j@RestControllerAdvice@RequiredArgsConstructorpublic class DefaultExceptionHandlerConfig { @ExceptionHandler(BeHappyException.class) //@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ResponseEntity beHappyExceptionHandler(BeHappyException e){ log.error("BeHappy Exception: {}",e.getMsg()); return ResponseEntity.internalServerError().body(e); }} 在使用路由...
gRPC协议在K8S环境下的负载问题
gRPC协议在K8S环境下的负载问题参考： https://www.lixueduan.com/posts/grpc/13-loadbalance-on-k8s/ https://www.cyub.vip/2021/11/09/k8s%E7%8E%AF%E5%A2%83%E4%B8%8B%E9%83%A8%E7%BD%B2grpc%E7%9A%84%E5%87%A0%E7%A7%8D%E6%96%B9%E6%A1%88/ 概述系统中多个服务间的调用用的是 gRPC 进行通信，最初没考虑到负载均衡的问题，因为用的是 Kubernetes，想的是直接用 K8s 的 Service 不就可以实现负载均衡吗。 但是真正测试的时候才发现，所有流量都进入到了某一个 Pod，这时才意识到负载均衡可能出现了问题。 因为 gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连接，所有请求都通过该连接进行多路复用。 这样虽然减少了管理连接的开销，但是在负载均衡上又引出了新的问题。 由于我们无法在连接层面进行均衡，为了做 gRPC 负载...
golang建立项目以及go-module和vendor的区别
$GOPATH默认位置 操作系统 默认路径示例 环境变量表示法 macOS /Users/用户名/go $HOME/go Linux /home/用户名/go $HOME/go Windows C:\Users\用户名\go %USERPROFILE%\go not a valid zip filegithub.com/shirou/gopsutil/process: zip: not a valid zip file 此类问题多是因为GOPROXY所导致。 使用https://mirrors.aliyun.com/goproxy/,direct的时候，在进行go build/go mod tidy等指令时就会出现此错误。 换成https://goproxy.cn,direct即可。 123456789101112131415161718192021$ mkdir go-example && cd go-example#GO111MODULE=on，使用go module，不使用GOPATH#GO111MODULE=off，使用GO...
pprof调优学习
Go性能优化 测试代码: https://github.com/behappy-project/behappy-url-shortener Go语言项目中的性能优化主要有以下几个方面： CPU profile：报告程序的 CPU 使用情况，按照一定频率去采集应用程序在 CPU 和寄存器上面的数据 Memory Profile（Heap Profile）：报告程序的内存使用情况 Block Profiling：报告 goroutines 不在运行状态的情况，可以用来分析和查找死锁等性能瓶颈 Goroutine Profiling：报告 goroutines 的使用情况，有哪些 goroutine，它们的调用关系是怎样的 采集性能数据Go语言内置了获取程序的运行数据的工具，包括以下两个标准库： runtime/pprof：采集工具型应用运行数据进行分析 net/http/pprof：采集服务型应用运行时数据进行分析 pprof开启后，每隔一段时间（10ms）就会收集下当前的堆栈信息，获取各个函数占用的CPU以及内存资源；最后通过对这些采样数据进行分析，形成一个性能分析报告。...
robfig_cron_v3,cron工具类
基于(robfig_cron开发一个小工具)包: https://github.com/robfig/cron123go get github.com/robfig/cron/v3@v3.0.0import "github.com/robfig/cron/v3" util123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104package utilimport ( "github.com/pkg/errors" cron "github.com/robfig/cron/v3" "sync")// Crontab crontab managertype ...
单元测试介绍及使用
前言开发人员写的常常是“单元测试”，但其实可以细分成 单元测试 和 集成测试 两个。 划分的原因拿常见的 Spring IoC 举例。Spring 不同Bean之间相互依赖，例如某API业务逻辑中会依赖不同模块的 Service，Service 方法中又可能依赖不同的 Dao 层方法，甚至还会通过 RPC、HTTP 调用外部服务方法。这给我们写测试用例带来了难度，本来只想测试某个方法的功能，却要考虑一连串的依赖关系。 单元测试 单元测试：是指对软件中的最小可测试单元进行检查和验证。 通常任何软件都会划分为不同的模块和组件。单独测试一个组件时，我们叫做单元测试。单元测试用于验证相关的一小段代码是否正常工作。单元测试不是用于发现应用程序范围内的 bug，或者回归测试的 bug，而是分别检测每个代码片段。 单元测试不验证应用程序代码是否和外部依赖正常工作。它聚焦与单个组件并且 Mock 所有和它交互的依赖。例如，方法中调用发短信的服务，以及和数据库的交互，我们只需要 Mock 假执行即可，毕竟测试的焦点在当前方法上。 单元测试的特点： 不依赖任何模块。 基于代码的测试，不需要在 A...
公告