Your question is a very good one. It touches on both points of multithreaded
programming:
Synchronization and memory coherency (memory barrier). Had vector been
implemented in java 1.5 or later, it wouldn't make much sense to synchronize
on these two methods. It's enough to declare the relevant vars as volatile.
But pre-1.5 volatile semantics was different, and synchronized was the only
way to add memory barrier.
【在 r******r 的大作中提到】 : 比如,Vector 的两个方法: : public synchronized int capacity() { : return elementData.length; : } : public synchronized int size() { : return elementCount; : } : elementCount 是 int. 学多线程,不明白。无修改操作,为什么需要保护?
I feel members like "size" & "capacity" are highly time sensitive in
multiple threading environment. It's accurate at a time point。By‘not
accurate', I think you mean the value of size changes quickly because of
concurrent accesses. It doesn't really mean it's wrong; otherwise the
concurrency isn't thread safe, which isn't the case.
Are I missing something?
"Most classes in concurrency package allow concurrent access."
Regrading this, how about this:
Collection
【在 r******r 的大作中提到】 : I feel members like "size" & "capacity" are highly time sensitive in : multiple threading environment. It's accurate at a time point。By‘not : accurate', I think you mean the value of size changes quickly because of : concurrent accesses. It doesn't really mean it's wrong; otherwise the : concurrency isn't thread safe, which isn't the case. : Are I missing something? : "Most classes in concurrency package allow concurrent access." : Regrading this, how about this: : Collection
Most modern implementation uses an integer field to track size so it's not a
heavy operation at all.
The returned collection in your example is synchronized already so there's
no need to put it in a synchronized block. Plus, your way of synchronizing
over the object itself while it's synchronized looks weird.
Accessing of the collections in concurrent packages are still thread safe.
However, getting precise size in a multi-threading dynamic environment
usually means very little since it's a moving target all the time which can
be hardly relied on, unless, of course, you put everything in a synchronized
block, which is usually bad design and beats the whole purpose of the new
concurrency packages.
【在 r******r 的大作中提到】 : I feel members like "size" & "capacity" are highly time sensitive in : multiple threading environment. It's accurate at a time point。By‘not : accurate', I think you mean the value of size changes quickly because of : concurrent accesses. It doesn't really mean it's wrong; otherwise the : concurrency isn't thread safe, which isn't the case. : Are I missing something? : "Most classes in concurrency package allow concurrent access." : Regrading this, how about this: : Collection
r******r 发帖数: 700
68
"The returned collection in your example is synchronized already so there's
no need to put it in a synchronized block."
I agree with you on this. However, read this from Java API Doc. Especially
in the iteration,there is no modification.
" It is imperative that the user manually synchronize on the returned
collection when iterating over it:
Collection c = Collections.synchronizedCollection(myCollection);
...
synchronized(c) {
Iterator i = c.iterator(); // Must be in the synchronized block
while (i.hasNext())
foo(i.next());
}
Failure to follow this advice may result in non-deterministic behavior. " http://docs.oracle.com/javase/6/docs/api/java/util/Collections.
a
can
synchronized
【在 c*m 的大作中提到】 : Most modern implementation uses an integer field to track size so it's not a : heavy operation at all. : The returned collection in your example is synchronized already so there's : no need to put it in a synchronized block. Plus, your way of synchronizing : over the object itself while it's synchronized looks weird. : Accessing of the collections in concurrent packages are still thread safe. : However, getting precise size in a multi-threading dynamic environment : usually means very little since it's a moving target all the time which can : be hardly relied on, unless, of course, you put everything in a synchronized : block, which is usually bad design and beats the whole purpose of the new
g*****g 发帖数: 34805
69
It would be accurate if only one thread is allow to operate on the
collection, which is not the case for class like ConcurrentHashMap.
s
【在 r******r 的大作中提到】 : "The returned collection in your example is synchronized already so there's : no need to put it in a synchronized block." : I agree with you on this. However, read this from Java API Doc. Especially : in the iteration,there is no modification. : " It is imperative that the user manually synchronize on the returned : collection when iterating over it: : Collection c = Collections.synchronizedCollection(myCollection); : ... : synchronized(c) { : Iterator i = c.iterator(); // Must be in the synchronized block
I see what you are trying to achieve.Yeah the provided synchronization is on
the method level. If a node is added or removed while the collection is
being iterated over, it's going to throw an cocurrentmodificationexception.
Nonetheless I do think this is the only case you need to synchronize on the
whole collection, and should be avoided in general. If you do need to
iterate, try copyonwritearray which you can iterate without blocking
everyone else.
s
【在 r******r 的大作中提到】 : "The returned collection in your example is synchronized already so there's : no need to put it in a synchronized block." : I agree with you on this. However, read this from Java API Doc. Especially : in the iteration,there is no modification. : " It is imperative that the user manually synchronize on the returned : collection when iterating over it: : Collection c = Collections.synchronizedCollection(myCollection); : ... : synchronized(c) { : Iterator i = c.iterator(); // Must be in the synchronized block
for (int i = 0; i < vector.size(); i++)
doSomething(vector.get(i));
above iteration may throw ArrayIndexOutOfBoundsException. so, better lock it.
synchronized (vector) {
for (int i = 0; i < vector.size(); i++)
doSomething(vector.get(i));
}
if the modification count that associated with the collection changes during
iteration, hasNext or next throws ConcurrentModificationException.
s
【在 r******r 的大作中提到】 : "The returned collection in your example is synchronized already so there's : no need to put it in a synchronized block." : I agree with you on this. However, read this from Java API Doc. Especially : in the iteration,there is no modification. : " It is imperative that the user manually synchronize on the returned : collection when iterating over it: : Collection c = Collections.synchronizedCollection(myCollection); : ... : synchronized(c) { : Iterator i = c.iterator(); // Must be in the synchronized block
My opinion, vmware is the best, ask some experienced users do an image for
you. Don't do tomcat/jboss, linux, database, build tools, and other
installation. It is irrelevant and waste a lot of time. Most java developer,
typical junior/intermedia, in the company environment, dont touch these
process, you just do code, follow check in process.
So, get a mentor, he/she should set up everything for you the same as at
work, do you a vm image, and you just do code, unit test, and check in, and
the mentor build it for you, test for you. Enough, if he is really nice, he
can review the code together with you, but not necessary.
Once you are comfortable, get a real job, and when you have money, energy
and time, you can build your own environment, installation, admin is pretty
straight forward, if someone show you once, you should be able to do it.
Most interviewer only care if you know java. And no way for him to test if
you know the build script or not, unless the job is specific for
configuration management or CI.
Another option is that someone write you the build scripts, you just do edit
, package/build and deploy, "mvn package" is enough, or if the build script
includes database and app server, and others, everything, maybe you just do
mvn jetty: run.
Or you can try spring roo, but I think most company still dont use it. So
you might learn something that you never use.
【在 r******r 的大作中提到】 : 自己弄弄,可以学的快, 知道是怎么回事
x****d 发帖数: 1766
92
I am against this idea, it is very old fashion, I see people waste a lot of
time on this. see my other post for suggestion.
developer,
and
he
大牛只是说对了一半。其实用vmware的cloudfoundry就可以了。
【在 x****d 的大作中提到】 : My opinion, vmware is the best, ask some experienced users do an image for : you. Don't do tomcat/jboss, linux, database, build tools, and other : installation. It is irrelevant and waste a lot of time. Most java developer, : typical junior/intermedia, in the company environment, dont touch these : process, you just do code, follow check in process. : So, get a mentor, he/she should set up everything for you the same as at : work, do you a vm image, and you just do code, unit test, and check in, and : the mentor build it for you, test for you. Enough, if he is really nice, he : can review the code together with you, but not necessary. : Once you are comfortable, get a real job, and when you have money, energy
z****e 发帖数: 54598
94
只有一年免费,还不如open shift
【在 x****d 的大作中提到】 : try Amazon EC2, one year free. :
x****d 发帖数: 1766
95
and heroku.
but I dont like them, the key is mimicking work environment, right?
【在 p*****2 的大作中提到】 : : developer, : and : he : 大牛只是说对了一半。其实用vmware的cloudfoundry就可以了。
F****n 发帖数: 3271
96
典型的ICC廉价码农模式
developer,
and
he
【在 x****d 的大作中提到】 : My opinion, vmware is the best, ask some experienced users do an image for : you. Don't do tomcat/jboss, linux, database, build tools, and other : installation. It is irrelevant and waste a lot of time. Most java developer, : typical junior/intermedia, in the company environment, dont touch these : process, you just do code, follow check in process. : So, get a mentor, he/she should set up everything for you the same as at : work, do you a vm image, and you just do code, unit test, and check in, and : the mentor build it for you, test for you. Enough, if he is really nice, he : can review the code together with you, but not necessary. : Once you are comfortable, get a real job, and when you have money, energy
p*****2 发帖数: 21240
97
大牛说的对。我坚决不用。现在免费的太多了。
【在 z****e 的大作中提到】 : 只有一年免费,还不如open shift
p*****2 发帖数: 21240
98
focusing on coding only. Also you can get a real deployment in cloud.
【在 x****d 的大作中提到】 : and heroku. : but I dont like them, the key is mimicking work environment, right?
x****d 发帖数: 1766
99
why junior need something in cloud? to waste time or to disclose that he is
junior?
My suggestion was focusing coding only too, but in a real work environment.
【在 p*****2 的大作中提到】 : : focusing on coding only. Also you can get a real deployment in cloud.
x****d 发帖数: 1766
100
what is icc? good or bad? black cat white cat, getting rat is good cat.
【在 F****n 的大作中提到】 : 典型的ICC廉价码农模式 : : developer, : and : he
open shift可以提供免费的3 gears的服务
而且是标准的j2ee组件,对付个人网站足够了
【在 x****d 的大作中提到】 : all useless.
x****d 发帖数: 1766
103
why use java for personal site? so much time to kill? aws ec2 you can try
hadoop etc. almost everything. There is one click install images for all
kinds of java stacks, like jboss + mysql, jboss + liferay...
【在 z****e 的大作中提到】 : open shift可以提供免费的3 gears的服务 : 而且是标准的j2ee组件,对付个人网站足够了
z****e 发帖数: 54598
104
目测某人只是想找个地方练手而已
【在 x****d 的大作中提到】 : why use java for personal site? so much time to kill? aws ec2 you can try : hadoop etc. almost everything. There is one click install images for all : kinds of java stacks, like jboss + mysql, jboss + liferay...
x****d 发帖数: 1766
105
exercise what yah, just code and unit test, all else are useless skills at
the very beginning.