-
现在的“双链”笔记的发展是否走进了误区?
2024-04-22 15:29我且认为“好的设计是趋同的”,“超乎寻常的论断需要超乎寻常的证据”
仅凭几句“我觉得”还很难谈论到“是否进了误区”的地步
我认为你的认为还不够成熟
还需要多看,多学习,多体会
不要总想搞个大新闻
-
大家能看出这段代码的问题么?
2024-04-11 17:09“大人,时代变了”
这段代码实现了异步执行一个事件的功能。它创建了一个单线程的
ExecutorService
,然后使用这个服务执行一个FutureTask
,这个FutureTask
中包含了真正的事件执行逻辑。虽然这段代码能够工作,但是它有几个潜在的问题和改进的地方:- 资源泄露: 每次调用
fireEventAsynchronously
方法时都会创建一个新的ExecutorService
,但是这个服务并没有被明确地关闭。如果这个方法被频繁调用,那么将会创建大量的线程池,但这些线程池不会被自动回收,最终可能导致资源耗尽。为了避免这个问题,可以考虑使用一个共享的ExecutorService
,并在适当的时候关闭它,或者使用try-with-resources
确保每个创建的服务都能被正确关闭。 - 返回值问题: 这个方法的返回类型是
Future<T>
,但在Callable
的实现中返回的是null
。这意味着,即使调用者期待一个结果,也得不到有意义的返回值。这可能不是设计上的问题,但如果有返回值的期待,应该重新考虑这个实现。 - 异常处理:
Callable
中的call
方法抛出了一个异常,但是在异步执行的环境中,异常的处理会比较复杂。调用者需要明确地从返回的Future
中检查和处理异常,这可能是一个容易被忽视的地方。 - 同步问题: 代码中使用了
synchronizedEventQueue.fireEvent(event);
进行事件触发,这表明可能存在对事件队列的同步控制。但是,在异步执行的环境下,仅仅依靠方法级别的同步可能不足以保证线程安全,具体取决于synchronizedEventQueue
的实现和使用方式。 - 效率问题: 如果事件处理通常很快,使用单独的线程池可能是一个过重的解决方案,因为线程的创建和销毁都是昂贵的操作。在这种情况下,可以考虑使用一个已经存在的线程池,或者其他轻量级的并发机制。
综上所述,虽然这段代码能够实现基本功能,但在实际使用中可能会遇到资源管理、性能和设计上的问题。考虑到这些潜在问题,重构代码以使用共享的
ExecutorService
,改善异常处理和同步机制,以及澄清方法的返回值,都是值得考虑的改进方向。 - 资源泄露: 每次调用
-
思源笔记的核心优势是什么?
2024-04-06 00:25双链 + 本地 + 开源 + 插件 + 闪卡 + 手机伺服 + 敏捷开发 + 男女搭配干活不累
算是形成合力,复合优势吧
就算还有啥不顺手,也可以探讨,说不定下个版本更新上了
-
刚刚看了大神对思源的分析,再不叫停数据库和白板功能,思源就要寄了
2024-03-24 01:18我不是写代码的,对数据也不了解,但感觉这个大神分析的非常合理
这是什么虎狼之词
不懂,就多学习,多问“为什么”
既然能写这么多字,不太相信楼主具有巨婴一般的“阅读能力”帖子的评论很重要,那是社区的重要的不同的“声音”,建议再回去读一下
-
能不能做得像 Evernote 国际版那么好用?
2023-12-19 11:27郭德纲:内行要是与外行去辩论那是外行。比如我和火箭科学家说,你那火箭不行,燃料不好,我认为得烧柴,最好是煤,煤最好选精煤,水洗煤不好。如果那个科学家拿正眼看我一眼,那他就输了
-
能不能做得像 Evernote 国际版那么好用?
2023-12-04 21:37以下是我的个人偏见,和上不得台面的建议
公共场合不建议使用反问句
公共场合不建议使用反问句
公共场合不建议使用反问句
(可能我这算是恨屋及乌吧,心态失衡了,属于是)
-
能不能做得像 Evernote 国际版那么好用?
2023-12-04 21:31子曾经曰过:先问是不是,再问为什么
那我觉得 Evernote 很垃圾,完全不值得学。
本来这是件不言而喻的事情,但我还是想拉出咱论坛的大佬来背书一下
(此处简单 @dee… 不敢写全,毕竟大佬不能随便打扰的)
你猜怎么着,就突然发现了这么两篇文章
如果楼主依然坚持他好,那就是尊重楼主的好恶
毕竟 Evernote 已经被收购到欧洲,美国全体被裁
前两天已经出了“免费用户一个笔记本,50 条笔记的”的自宫绝招
如果我没记错的话可能是今天(12 月 4 号)就生效了
下一步我就等着他们挂掉了,乐乐呵呵的看着
要问我为何如此这般?
毕竟她啊,是俺 PKM 的启蒙
曾经也对我俩的美好未来无限憧憬
后来,她…
反正她的下场已经如此了