首页   注册   登录
 wly19960911 最近的时间轴更新

wly19960911

V2EX 第 115352 号会员,加入于 2015-05-05 19:11:30 +08:00
目前 react 流行的路由缓存策略是什么 ?
问与答  •  wly19960911  •  215 天前  •  最后回复来自 wly19960911
6
idea 2019.1 加入了定制 theme 功能
分享发现  •  wly19960911  •  253 天前  •  最后回复来自 karllynn
5
pc 版 chrome ,也有 pwa 入口了
分享发现  •  wly19960911  •  261 天前  •  最后回复来自 LAIchimi
9
基于 flutter 做的 yande 第三方 app
分享创造  •  wly19960911  •  292 天前  •  最后回复来自 wly19960911
5
aria2 的 BT 下载真的快吗?
问与答  •  wly19960911  •  181 天前  •  最后回复来自 gkiwi
19
wly19960911 最近回复了
3 天前
回复了 EEEcho 创建的主题 优惠信息 薅 10086 羊毛
阻止携号转网的说法根本站不住脚,移动早就有了这个,而且阻止携号转网就 3 个月有点说不过去吧。

这个是移动难得的福利,而且本身我就移动大王卡,完全没理由转网
18 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
状态不好,老打错字,忽略下五楼

”阻塞和非阻塞是相对的,同步代码下面你还是会被阻塞“ => "同步和异步是相对的,同步代码下面你会被阻塞"
18 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
”同步和异步是相对的,同步代码下面你还是会被阻塞“ => "阻塞和非阻塞是相对的,同步代码下面你会被阻塞"
18 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
@ruandao 我可能解释错误了,不好意思,阻塞和非阻塞是相对的,同步代码下面你还是会被阻塞,多线程的某个线程你仍然也会被阻塞,但是多线程仍然是异步。而阻塞和非阻塞是因为非阻塞采用了事件队列进行轮询 / event loop,这种非阻塞式 IO 的模型实现的,将事件拆成回调的形式,等辅助用的 IO 线程结束后,才将回调加入队列里面等待执行,最大程度的减少阻塞和线程切换开销。

另外你可以认为 worker thread 就是用户线程,通过队列机制,采用回调机制来安排 worker thread 减少开销。再上面的 协程 就是利用回调链,包装一次回调函数,让回调不用写在回调函数里面而是写成链式或者同步的样子( async await )。
19 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
@wly19960911 记错单词, 是 worker thread ,工作线程。
19 天前
回复了 ruandao 创建的主题 问与答 阻塞 非阻塞 ? IO 模型 请教下
阻塞和非阻塞指的是 work thread,如果是异步阻塞的话,需要更多的 work thread 带来的开销更大,而异步非阻塞能使用少量的 work thread 来排队,而 io 线程交给线程池处理,减少开更多线程的切换开销,适合 IO 密集型而非 计算密集型。
21 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@wysnylc 但是我是 rxjs (跑

不过到时候看看 flow 是什么情况,毕竟我也用 Java
21 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@WenhaoWu rxJava 的 catch 和 trycatch 没什么区别,讨论的核心还是要不要 catch。是我 do/tap/map 里面判断掉然后 filter 还是用 throw Error,来进行流程控制。

我感觉会 Rx Java 就没必要参与这个讨论了…Rx Java 本来就是一套流程控制库,充分使用自然知道会使用自己认为更好的策略
21 天前
回复了 Simle100 创建的主题 Java 方式 1 和方式 2 的却别到底在哪里?
@crclz 跟我想法一样。不过 dalao 还是更简练深刻,我讲的废话多…大佬有兴趣看我回复记录就能看见了。


@wysnylc 难怪开了一贴,原来在这里讨论…哈哈哈
21 天前
回复了 wysnylc 创建的主题 Java 为什么不建议用 try catch?
@wysnylc 其实我这里也没有聊兼容性和扩展性,这个更多需要依赖业务和经验,可惜我也对这块也不是很熟悉。我工作经验还不是很久。

但是我能充分感受到的是,不用 try catch 最大的原因是因为看了一段代码之后,会开始思考究竟需要再哪个流程 try catch,那个流程怎么进行 try catch。但是往往面临的问题是我自己连 try catch 在哪里都不一定能确定下来

比如 一个 (流程 A) 里面执行了 (方法 B) ,B 执行了 (方法 C) ,A 结束之后执行 (流程 H),但是这个时候 C 里面 throw 了 error,我需要在 流程 A 里面处理,但是问题是我需要来自 B 的数据。这时候这个代码就写的一塌糊涂。这还是 3 层,如果是 4 层、5 层呢,怎么处理?


@lcdtyph 在运行效率面前我选择工作效率,如果舍弃了 try catch 还出了性能问题,那么已经是无力挽回了。有流程控制还能想办法优化。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2198 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 18ms · UTC 05:15 · PVG 13:15 · LAX 21:15 · JFK 00:15
♥ Do have faith in what you're doing.