g*****g
发帖数: 34805 | 1 你这个也太夸张了吧。一个constructor有多难，对轻量级的task类，用constructor放
一个
参数进去，对性能根本没影响。
input
Future |
|
g*****g
发帖数: 34805 | 2 You init N threads threadpool, each thread is associated with a Predictor,
you simply pass your task to the threadpool. |
|
o**2
发帖数: 168 | 3 int cores = Runtime.getRuntime ().availableProcessors ();
补充一点，default的new Messenger（）使用上面的core数量作为threadpool的容量。
如果不涉及IO，光是计算的话，这些threads足够用了，超过硬件的core数的话，就浪
费了。 |
|
T***B
发帖数: 137 | 4 照着mectite，goodbug二位的思路写了一下，代码如下. 试着跑了一下，运行结果和预
期吻合。我有一个问题：我在PredictRequest.call()里面把current thread cast成
PredictorThread从而拿到predictor object. 还有更好的办法把predictor (inside
the thread) 和callable联系起来吗？
Predictor.java
public class Predictor {
private String name;
public Predictor(String name) {
// heavy lifting stuff.
this.name = name;
System.out.println("Created predictor " + name);
}
public synchronized String predict(String input) throws
InterruptedExcept... 阅读全帖 |
|
|
g*****g
发帖数: 34805 | 6 Put the predictors in a blocking queue. In your Callable do a queue.get and
queue.put before and after, the code is much cleaner. You don't need to
synchronize in the Predictor BTW. |
|
T***B
发帖数: 137 | 7 goodbug, I like your idea of putting predictors in a blocking queue. thanks.
My real implementation of predict method has to be synchronized to
ensure thread safety. Synchronization on this method is the primary
reason that I need a group of preditor objects (as opposed to one)
to avoid the performance bottleneck in this method when multiple threads
are making predict calls. |
|
g*****g
发帖数: 34805 | 8 In the proposed change, your predictors are not shared by threads. And you
don't need to sync them.
thanks. |
|
s******e
发帖数: 493 | 9 Using queue, especially blocking queue, even on the surface looks more
elegant since you can avoid casting. But it actually will cost you more
trouble down the road if you want any nontrivial implementation.
By separating something really closed to each other, you need to handle
their life cycles separately for any elegant implementation. Issues you
might need to consider:
1. The queue should have the exactly same life cycle as the thread if the
predicator instances won't be used anywhere else. ... 阅读全帖 |
|
o**2
发帖数: 168 | 10 把FMP的版本又优化了一下，很容易就把constructor()和predict()给放到一个active
object里去了，不但constructor()的执行是在worker thread里，而且是on demand的。
在使用原Predictor class的前提下，只增加了PredictorActiveObject和
PredictService这两个classes。
// FMP guarantees every instance a single-threaded env
public class PredictorActiveObject {
private static final AtomicInteger created = new AtomicInteger ();
private Predictor predictor;
// single-threaded
public void init () {
if (predictor == null) {
predictor = new Pre... 阅读全帖 |
|
o**2
发帖数: 168 | 11 如果楼主可以把contructor()里的logic搬到一个init() method里的话，那就没有必要
加新class了，改造原先的Predictor和PredictService就够用的了。
从下面列出原问题的FMP终结版可以看出，FMP和thread，thread pool，
ExecutorService等并发编程技术相比，就象C语言和汇编语言相比，那是全方面的胜出。
public class Predictor {
private boolean inited = false;
// instance-wide single-threaded
public void init () {
if (inited) {
return;
} else {
inited = true;
}
// heavy lifting stuff from original constructor
}
// instance-wide singl... 阅读全帖 |
|
c*********e
发帖数: 16335 | 12 好奇地问一下，这些class是用在web application里，还是application里？
如果是web application里，每一個用戶登录进去后，private boolean inited的值，
每个用戶都能更改，因为它不是session variable.这个大家怎么解决的？
public class Predictor {
private boolean inited = false;
出。 |
|
o**2
发帖数: 168 | 13 我不是很理解你的问题，这些是POJO，用在哪里它都遵循Java language的定义啊。
根据楼主的介绍，我估计他的程序要么是一个batch job，要么是一个back office的
engine。这些class的instance肯定不是直接为每一个http connection创建和服务的。 |
|
c*********e
发帖数: 16335 | 14 抱歉。因为我web application做得很多，所以对session variable很敏感。 |
|
T***B
发帖数: 137 | 15 smectite, you raised an very important point.
If we start with the requirements, what I need is a group of predictors that
can independently make predictions within a JVM. Some characteristics of
the system:
- Initializing a predictor is time consuming.
- A predictor, once initialized, holds non-trivial amount of memory.
- Predict call is CPU intensive. predict() method is not thread safe.
- A client request triggers a batch of predict calls. Batch size can vary.
From design perspective, what I'... 阅读全帖 |
|
g*****g
发帖数: 34805 | 16 I think the problem is overstated. When the predictors are kept in a
separate blocking queue, they don't have to have the same life cycle as
threadpool, which gives you more flexiblity. And if you want to tie them,
you can always override shutdown method of the threadpool. Also Predictor is
not affected by predict calls, I don't see how they can be corrupted.
In fact, in a complicated server app, this separation makes it possible to
send these tasks to a generic threadpool.
framework |
|
s******e
发帖数: 493 | 17 well I believe it was understated in this use case. What concern the author
most were performance and memory footprint. By take advantage of the built-
in life cycle mechanism of the executor framework, coders can very much
delegate the predicator instance management to the executor framework. This
will guarantee both the performance (no thread needs to wait for next
available predicator instance) and memory footprint concerns (shrink and
recreates if needed. or fixed...) this provides the exact... 阅读全帖 |
|
o**2
发帖数: 168 | 18 Give each Predictor object its own thread, and apply producer/consumer
pattern twice: one is from user thread to predictor thread for dropping off
prediction input, and the other one is form predictor thread to user thread
for picking up computed prediction.
public class Predictor implements Runnable {
private String input, prediction;
private boolean stop;
public Predictor () {
new Thread (this).start ();
}
public synchronized boolean isIdle () {
return input... 阅读全帖 |
|
c*********e
发帖数: 16335 | 19 高手，这code你写的吗？
off
thread |
|
o**2
发帖数: 168 | 20 我在mitbbs上混了几个月了，一直是码工本色，用代码说话，你没有注意到吗？那我还
要再多写代码才行。
这是很简单的应用producer/consumer的例子，虽然很多行，但概念很简单，十分钟就
可以写一个这样的程序。由于主要是给楼主参考借鉴用的，所以也没有检查所有的
thread interleaving的地方，也许会有错。
这个例子也展示了直接用thread写并发程序的困难性：新手入手难，熟手也不能完全保
证正确性。我个人认为楼主的上策应该是选用FMP，中策是选用直接的thread，下策是
thread pool。 |
|
g*****g
发帖数: 34805 | 21 这年头还有自己从头写的？producer/consumer的例子现成的一大把。
会google会改就够了。 |
|
|
|
r*****s
发帖数: 985 | 24 安啦，
不同牛人的不同表现方式而已。
我也是google的多，
java的好处就是lib一堆，
比如前面那个compare string的，
那管什么"".equals(str)的优化？
直接if(StringUtils.isEmpty(str))就好了。 |
|
|
t***a
发帖数: 416 | 26 大赞阿，看着挺有意思的，支持！
你一个人维护？放哪了？ |
|
|
r*****s
发帖数: 985 | 28 您老早说啊，
我们都捧捧场，
就是杀鸡也用您牛人的刀！ |
|
t***a
发帖数: 416 | 29 不错不错，还有maven, 现在我感觉我都不太会部署local jar了
你那个javascript的fms是啥思路啊？怎么用的? |
|
s******e
发帖数: 493 | 30 public Predictor () {
new Thread (this).start ();
}
Interesting... I believe this is against java publication safety rule.
Did you try to run pmd and firebug on it? |
|
o**2
发帖数: 168 | 31 那太太太感谢了，有github帐号的话就捧捧场吧。
FMP的确可以杀鸡（level of object），也可以屠龙（level of cloud apps）。现在
的切入点是杀鸡工具。 |
|
o**2
发帖数: 168 | 32 你说的完全有可能，我自己都不熟悉你提到的“java publication safety rule”。
你的第二句是啥意思啊？ |
|
|
t***a
发帖数: 416 | 34 很有意思，js项目里组织代码一直很困扰我，试了好多方式，到现在也还是摇摆不定，
很纠结
help |
|
r*****s
发帖数: 985 | 35 akka那个是不是跟您这个类似啊，
比较一下？
help |
|
t***a
发帖数: 416 | 36 scala下akka接口还可以，java下，真心不如楼主这一套简单实用
不过akka线程池可以分布式的，不知道楼主这个能部署成分布式的吗 |
|
s******e
发帖数: 493 | 37 PMD and findbugs are code style checking tools.
just quickly take a look at your code this page. I believe what you try to
do is exactly what executor framework tries to resolve. Since they do that
in a more elegant way. I do not see why we should reinvent wheels in a much
harder way. |
|
t***a
发帖数: 416 | 38 谁能来科普一下 ，什么是java publication safety rule啊，我等下文等了一下午了
。。。。 |
|
o**2
发帖数: 168 | 39 可以说核心都是actor的思想，akka用户是使用裸体的actor，FMP的用户是通过
messenger使用active object。这个archtecture上的不同导致了vision的完全不同，
FMP完全是跨语言跨平台。不同语言不同平台上的不同active object可以用自始至终不
变的API互相调用/通讯，比如一个C#写的active object在messenger1里在Windows上可
以这样调用另外一个Java写的active object "calculator"which运行在messenger2在
Linux上：
messenger1.callService("messenger2::calculator:multiply", n1, n2);
（当然前提是messenger1和messenger2已经直接或间接地connected，FMP叫它们
networked messengers。模型和设计都完成了，就等有空的时候，我写一个reference
implementation。）
（n1和n2要是合适的数据，比如可以写成JSON的。FMP不管数据转换的... 阅读全帖 |
|
s******e
发帖数: 493 | 40 go read java concurrency in practice. It has the detailed explanation. In
short, for this case, you can not publish a reference of an object to
another thread from its own constructor since the object might not be
appropriately constructed yet. |
|
o**2
发帖数: 168 | 41 可以，不但是分布的，还可以是跨语言跨平台的。（pls refer to my other replies
，and 现在没有implementation，will be available in near future。） |
|
o**2
发帖数: 168 | 42 没有用过code style checking tools。
我把一个thread完全隐含到一个Predictor的instance里面，对这个问题来说，是最符
合OOP设计原则的，同时也符合原要求。虽然内部有很多代码做interleaving的
checking，看起来很繁琐，但原则很简单。会producer/consumer pattern的程序员都
能写和接手这个程序。
Executor framework是基于task的，在这个问题上，只会把class弄的一团糟，后续的
维护和调整将会相当困难，比如一个Predictor的instance有问题了（要检测方便）要
换一个新的instance等。
建议你也动手写一个Executor版本的代码，贴出来我们分析讨论一下。
much |
|
o**2
发帖数: 168 | 43 你说的这个并不是thread特定的问题，当程序进入constructor时，JVM就已经把这个
instance建立起来了，然后的问题就是这个instance的internal state，也就是它的
instance变量，有可能在一个或多个constructor中有变化，而这些变化是不应该暴露
给外面的世界，相当于transaction的内部阶段。
我的代码没有这个问题，Predictor的constructor不改变instance的internal state。 |
|
o**2
发帖数: 168 | 44 顺便提一下，这个问题在Observer pattern多的地方（比如GUI）有可能变得很严重。 |
|
s******e
发帖数: 493 | 45 Haha if you can wait... I might write my own executor framework if I really
wanna kill my spare time.
Just do me a favor, go read the book. your code is almost the exact example
they use to show what a bad code will be.
No offense, I know you put tons of efforts in your project and I admire it.
Since I did not really spend any time on looking at your project, I cannot
comment on it. But I have written several wrappers on top of executor
framework for some specific tasks. I really feel that execu... 阅读全帖 |
|
t***a
发帖数: 416 | 46 你说的这个问题很常见，你是对的，在对象创建的过程中，publish它的引用会有产生
问题 |
|
o**2
发帖数: 168 | 47 你这个太长了，我分楼答复你。
really
example
.
is
threaded
they |
|
o**2
发帖数: 168 | 48 我没有提过让你写“my own executor framework”啊，我是说请你用你认为最好用的
JDK现有的executor framework帮楼主写他的Predictor和PredictorService classes。
我在这个帖子里每次写的code大约都是用十几二十分钟，所以应该不会占用你太多时间。
really wanna kill my spare time. |
|
o**2
发帖数: 168 | 49 我听你的，把第三章的Sharing Objects从第33到54页又读了一遍。发现就是按这本书
里说的标准，你对我的程序的判定也是错的，没有根据的。因为它说的是“Mutable
objects must be safely published, and mush be either thread safe or guarded
by a lock.”。我写的程序（在41楼）完全符合它对安全的定义，就是instance变量都
guarded by a lock。
我在66和67楼的回复中说这是OOP encapsulation的要求，不但对constructor，对任何
一个能change internal state的method，都有这个要求。就是你要等change made，才
能去publish/notify外部的其他objects。
而且我说的OOP encapsulation这个知识，是Brian在第三章说的知识的来源。
example they use to show what a bad code will be. |
|
t***a
发帖数: 416 | 50 我的理解是这样的，两位大侠帮忙看看对不对啊
关于对于object, 如果它的constructor还没有完全运行完，就publish它的reference,
是不安全的，比如说他有成员变量或者inner class没有初始化完之类的问题， 这可
能会让其他thread拿到一个incomplete的对象，我觉得这和oop2大侠说的“instance变
量都guarded by a lock"不是一个事儿.
就算在constructor的最后一行去publish这个object的引用，也是不safe的，因为这里
可能还有子类继承的情况，可能有子类构造函数里初始化未完全
类似的情况还有constructor里面起新的thread...
但如果，这个class的所有成员都是final的呢，即便它的value是在constructor里初始
化的，我的理解是，应该也不会存在incomplete object的问题了，这就是scala cass
class的好处啊！！太爱scala了。。。。
guarded |
|
